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ABSTRACT 


Authentication is particularly important in the SAAM system because SAAM uses 
mobile code. These resident agents are loaded onto SAAM routers dynamically, and 
execute on the destination SAAM router. Mobile code in the SAAM system requires an 
authentication scheme to prevent an outsider from sending a malicious resident agent. 
The primary focus of this research is to find the best-fit authentication scheme for the 
SAAM system. 

SAAM with authentication can be used as the technical network infrastructure to 
support Network Centric Warfare (NCW) as described in JV2010. The prototype in this 
thesis authenticates new nodes that join a SAAM network using Kerberos. Signaling 
data, also called control traffic, is authenticated with a dynamic signature key that 
changes every two minutes. Once a SAAM node is authenticated, its identity is protected 
throughout the battle. 
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I. INTRODUCTION 


A. NCW NETWORK 

Joint Vision 2010 provides the long-term vision for the US military. Network 
Centric Warfare (NCW) is one goal of JV2010, given the present Revolution in Military 
Affairs (RMA) in our environment. The RMA is caused by the explosion of Internet 
technology. Network Centric Warfare is the idea that several military platforms will be 
on-line with each other, exchanging situational awareness in real time. Sensors, decision 
support systems and weapons will be distributed across multiple platforms rather than 
being autonomously placed on single platforms. For example, an airplane in flight will 
accept an enemy sighting directly from a ground tank. One major assumption of JV2010 
is that the underlying network technology will accommodate NCW. 

NCW is a concept. The applications of NCW can run on an active network. 
Server and Agent Based Active network Management (SAAM) is such an active network 
in prototype at the Naval Postgraduate School. SAAM can be used as the technical 
network infrastructure component to support NCW. SAAM is a technology for the 
generation after next. In Internet years, it’s about three years away from market. 

JV2010 contains several strategic principles that SAAM addresses from a 
technical perspective. 

• Fusion of network intelligence with platform sensors is what SAAM was 
designed to do. With SAAM, an airborne radar sensor can automatically open a 
high priority flow to a ground-based guided missile that is on the other side of 
the globe. 
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• SAAM provides information superiority via dynamically deployable resident 
agents, which parse information for the decision maker. 

• Dynamic changes in the warfare environment may best be accommodated by a 
network that dynamically changes during conflict, which SAAM does. An agile 
organization is best supported by an agile network infrastructure. SAAM can 
mutate on the fly, as needed. 

The following is a list of technical problems in making the NCW network and 
solutions that SAAM provides. 

1. Problem 

a. The current Quality of Service (QoS) protocols are inadequate for 
battle, because the network will behave like the current best effort service model. 
DiffServ and MPLS are some example protocols in use. The QoS model they use is 
based on class of service. Packets can be grouped into classes of service. The Olympic 
model of bronze, silver, and gold demonstrates three different classes of service. A node 
heading into battle will try to send important information as gold service. For example, a 
force recon marine who discovers an enemy platoon would want to communicate that 
information to friendly forces as fast as possible. With everybody sending gold traffic, 
QoS will fail because all traffic that is not dropped is gold. The network is now 
delivering best effort service, like the Internet of the 1990’s. 

b. QoS policy must be set ahead of time. 

c. Nodes can be administratively restricted to a certain level of service 
ahead of time, in the interest of protecting QoS. However, this command decision would 
be a mistake. The theory of NCW is to allow the important information to arrive when 
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and where it is needed, in real time. The network must be a tool to that end, and the 


restriction to not allow real time traffic is in conflict with NCW. 

d. Resource Reservation Protocol (RSVP) has a scalability problem. The 
QoS decisions are made on each router. RSVP introduces state into the routing fabric. 
State was taken out of IP to keep the IP protocol as simple as possible, and RSVP adds 
state back in. End to end state-full routing is difficult to scale. 

Solution: 

a. SAAM implements a better-fit QoS model for battle because the 
network will not fall back to best effort service. SAAM supports the flow based service 
model, meaning that a conversation on the network can be given its own priority if 
required. SAAM also supports the other two service models, best effort and class based. 
For clarification of these terms, please see the Spectrum of QoS Models section in this 
thesis. 

b. SAAM QoS policies are set in real time, not only ahead of time. 

c. There will always be QoS in flow-based routing, even during times of 
stress. Flow-based routing is a specific QoS guarantee provided on a per conversation 
basis. Each connection that has subscribed to flow-based routing is assigned its own flow 
identifier. For example, the highest priority can be granted to the CINC outgoing hotline. 

d. SAAM addresses the scalability problem by using servers in a 
hierarchy, much like the current Internet uses Domain Name Service (DNS). RSVP can 
still be used in SAAM as a signaling vehicle for flow-based QoS. 


3 



2. Problem 


Service level agreements are not extended across ISP boundaries with current QoS 
protocols. QoS is only experienced when an organization owns the entire network today. 
It is more likely that the military will be using civilian links for some traffic, including 
satellite downlinks from Globalstar for example. The NCW network must guarantee QoS 
from one end node all the way to the other end. 

Solution: SAAM accomplishes painless interoperability between ISP’s. A 
hierarchy of servers makes QoS decisions. One parent server between two ISP’s 
recommends QoS levels down to two child servers. Each ISP can accept or reject this 
recommendation, based on internal ISP policy. Each ISP must be SAAM enabled for this 
situation. In addition, SAAM allows for backward compatibility with legacy QoS 
protocols, such as RSVP. An RSVP packet that enters the SAAM fabric will be assigned 
a SAAM flow ID inside the SAAM fabric, and sent back out the destination end as an 
RSVP packet again. QoS across ISP’s is provided for by SAAM. 

3. Problem 

Router upgrades during battle are difficult to make today. Feature sets on routers 
are locked down today, restricting a QoS network from healing itself while still running 
packets. For example, most router operating systems usually require human intervention 
to add a new protocol and reboot the router to activate that protocol. A small tactical 
network may require a sudden boost in performance, during an ambush for example. The 
current Internet is not active. One minute of downtime for a reboot is not acceptable in 
NCW. 
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Solution: New protocols are added to SAAM on the fly, as needed by the flows. 
SAAM is an active network. Smart agents, called Resident Agents, are added to routers 
to do whatever is needed, including probing malicious nodes. The SAAM network can 
heal itself in milliseconds, even before a human is aware of technical problems. 

Auto configuration is built into SAAM. The SAAM network periodically checks 
all nodes. This signaling traffic introduces minimal overhead. Nodes that are down are 
dropped out of the network, and flows are automatically rerouted around the problem 
nodes, all without the end user’s involvement. 

4. Problem 

The current Internet has many security holes. One specific problem is to 
authenticate friendly nodes on the network. In NCW, the aircraft that flies into the battle 
space must be identified as friendly in real time. Today’s military uses Identification 
Friend or Foe (IFF) traffic on separate out of band networks, and one of the greatest 
problems is interoperability between stovepipe IFF systems. 

Solution: SAAM authentication will accommodate IFF traffic in band. The 
problems of interoperability are solved by virtue of all traffic using an IPv6 network. The 
SAAM prototype in this thesis authenticates new nodes that are added to the SAAM 
prototype. Initial key distribution is only discussed because the technology for this 
problem still does not yet exist. However, this thesis does authenticate new nodes that 
join a SAAM network using Kerberos and allowing for authentication in IPsec. Each 
signaling flow, called control traffic in SAAM, is authenticated with a dynamic signature 
key that changes every two minutes. This two-minute window allows the key to be very 
small. Signing and authentication is much faster than would be with a large long-term 







key. In summary, once a SAAM node is authenticated, its identity is protected 
throughout the battle. A stolen SAAM node from a downed aircraft is useless to the 
enemy. Future smart agents could run genetic algorithms to fingerprint and thwart enemy 
IW attempts. This thesis supports IFF traffic in NCW. 

B. RECOMMENDATION 

SAAM is one possible solution to the technical problems posed by NCW, and 
merits consideration as the network system to support NCW. 
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II. DOD REQUIREMENTS FOR QOS 


In addition to NCW, SAAM is also relevant to the US Navy’s present-day Fleet 
Network Operations Centers (NOC’s). The Navy has plenty of reasons to implement 
QoS control systems, such as the need for prioritizing unofficial e-mail packets below 
official Navy message packets. The ship to shore connectivity is often a bottleneck. The 
allocation of bandwidth on the ship to shore links is a particular QoS challenge to the 
Navy. Sensor and weapons systems will need real time traffic during battle. These are 
only a few of the Naval needs for QoS. 

A. SPECTRUM OF QOS MODELS 

Spectrum of QoS Models 

Service Models 

Best Effort Class Based Flow Based 

--► 

SAAM SAAM SAAM 

Current Internet MPLS Integrated Services 

Differentiated Service 


Figure 1. Spectrum of QoS Service Models 
Though there are many QoS implementations, there are three basic service 
models. Notice that SAAM covers the entire spectrum. This figure focuses on service 
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models only. The figure does not show signaling protocols, such as RSVP, or packet 
scheduling algorithms, such as Weighted Fair Queuing, Early Random Detection, and 
Weighted Early Random Detection. Using signaling protocols and scheduling 
algorithms implement Service models. 

Best effort is in effect on the Internet today. All packets on the network are in 
equal competition with each other. The next model, class based, groups packets into 
different classes. The Olympic model of gold, silver and bronze is an example of how the 
class based model works. Packets are grouped into one of three different classes, gold, 
silver or bronze. A silver packet will be delivered before a bronze packet, and a gold 
packet will be delivered before any other class. Within one class, all packets compete 
with each other. The problem with class based QoS is Service Level Agreements (SLA’s) 
between peer networks. Peering arrangements are between Internet Service Providers 
(ISP’s). There is no technical way to keep one ISP from sending all traffic in the gold 
class. Eventually, all ISP’s send gold traffic and the situation is forced back to the best 
effort model. For this reason, someone or something has to make decisions to authorize 
bandwidth use. 

Given the failure of human beings to effectively throttle back on low priority 
traffic, the concept of bandwidth broker was developed. A bandwidth broker is a special 
computer in the Internet that will decide which packets are allowed through at what 
priority. Developing a bandwidth broker is a field of research in itself and much 
information is available today on the World Wide Web. 

The flow-based model addresses the technical problem of how to assign priority. 
Each conversation on the network is assigned a unique flow, similar to a tcp stream. 
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Each flow is assigned a priority. In SAAM, this is a function carried out inside the server. 
The idea of a bandwidth broker is designed into SAAM from the start. For an in depth 
study on how SAAM compares to other QoS schemes, please refer to [Quek]. 

It is interesting to note how similar the message precedence in the AUTODESf 
system is to the class of service protocols today, such as DiffServ. The class of service 
model is like ranking a message with the Olympic model. The classes are gold, silver, or 
bronze. In the same way, AUTODIN message precedence has been labeled as Flash, 
Immediate, Priority, and Routine. 



DiffServ Olympic 
Model 

AUTODIN 

Priorities 

AUTODIN 
Required Delivery 
Times 

High 

Gold 

Flash 

10 min. 

Medium 

Silver 

Immediate 

2 hr. 

Low 

Bronze 

Priority 

12 hr. 



Routine 

24 hr. 


Table 1. Comparison of DiffServ With Autodin Message Precedence 


1. SAAM and Integrated Service 

SAAM is based on a flow-based model, providing the guarantee that the network 
will never behave like a best effort network. IntServ is another QoS scheme that provides 
flow based QoS. The advantage of SAAM over IntServ is that SAAM offloads the flow 
setup calculations from the routers. IntServ relies on each router to calculate the flow 
next hop, whereas is SAAM the server performs this calculation only one time. SAAM 
conserves CPU cycles over IntServ. 
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B. WHY SAAM MAKES SENSE TO THE MILITARY 

1. Relevance to Fleet NOC’s 

The Navy Fleet Network Operations Centers (NOC’s) have a need for QoS. For 
example, the AUTODIN message system, which has been operational since the mid 
1950’s, has become crowded with message traffic in areas and times of crisis. Wherever 
the Navy was active in the world, that was exactly where our messaging system was 
bombarded with traffic. To address this problem, the MINIMIZE system was instituted. 
All Commanding Officers (CO’s) were expected to review outgoing message traffic 
headed into the crisis area. The theory was that the CO’s would participate in keeping the 
network open for important messages by reducing the quantity of low priority traffic. In 
practice, however, the MINIM IZ E keyword often became an invitation for large 
intelligence reports deluging the AUTODIN network with flash precedence messages. 
The outcome of MINIMIZE was often precisely opposite of the intent. Human behavior 
is one limiting factor to QoS systems. Given the opportunity to decide if their traffic is 
important, people will tend to view their traffic as important and send the message into an 
already crowded network. 

C. OUR WORK ON SAAM 

SAAM is a software system designed to meet the needs of the Next Generation 
Internet, using IP version 6. A working prototype has been in operation at the Naval Post 
Graduate School since September 1999. [Vrable and Yarger] Several students have 
conducted research to enhance the prototype. Our work is to incorporate security. 
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1. Project Goal 


The goal of this project is to develop a security system into SAAM. Our work 
begins where similar research has already been done but was not integrated into SAAM 
because the SAAM prototype did not yet exist. [Hensley and Ludden] 

2. Scope of This Thesis 

The SAAM project requires an authentication mechanism specifically designed to 
prevent unauthorized requests throughout the SAAM Enterprise. At the same time, 
overhead must be kept to a minimum. Initial key distribution is a problem that will be 
explored, along with how to prevent replay attacks, which are becoming easier to do for 
any Internet user. SAAM signaling traffic is vulnerable to spoofing. Because SAAM is 
an active network, mobile code is sent across the network. These resident agents must 
come from a trusted source before they are executed. SAAM authentication will allow 
future SAAM server and router application developers the opportunity to continue inter¬ 
enterprise communications. 

We would also like to include some of our work on the business side of SAAM. 
The organizational behavior effects of SAAM on a tactical Information Warfare (IW) 
command are explored in depth. Please see the appendix, entitled "Organizational 
Behavior Effects of SAAM." 

It is assumed that the reader has some knowledge of basic network security. If 
not, then please refer to the appendix entitled "Authentication Primer" or use any of the 
sources listed in the References. 
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III. SAAM INTERNALS 


A. MAJOR COMPONENTS 

SAAM is an acronym for Server and Agent based Active Management. Several 
important ideas are contained in this name. 

The SAAM system is server based by design, which makes SAAM unique among 
all QoS over IP systems. Some QoS systems force the overhead calculations into each 
router, while SAAM offloads these calculations onto a dedicated server. Thus the routers 
are relieved of the overhead. 

Agent based means that there are smart agents in the network. These agents 
perform functions such as probing a node to test if the new node is an unauthorized node 
or is damaged. Artificial intelligence (AI) can be added to enhance these modular agents, 
to support backward chaining, make a decision and take action, all before human beings 
are involved. The entire decision cycle can take place within microseconds, near real 
time. 

Active networking is an emerging technology in the year 2000. One unique characteristic 
of active networking is the ability to run applications within the routing fabric. New 
applications are loaded and unloaded as needed. These resident agents include core 
routing modules such as a routing algorithm or a queue scheduler. The mobile code used 
in SAAM must be authenticated to protect the network from intruders. 

From the technical industry perspective, SAAM has been called several things, 
including layer-4 routing, active networking, QoS over IP, server based routing, state-full 
routing, and a smart network. SAAM incorporates all of these aspects into one system. 
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The current SAAM prototype uses IP version 6. IPv6 is being fine-tuned by the 
IETF to address the problems that IP version 4 has. All the benefits that are built into 
IPv6 are incorporated into SAAM by default. 

1. SAAM Servers 

A SAAM Server is similar to a helicopter viewing an area of highway traffic. 
With this view, the server is able to direct traffic to the best path between a source and 
destination. The best path may be the least congested path among all possible paths, or 
one that will optimize the sum of all resources available. The Path Information Base 
(PIB) module in a SAAM server performs the functions of a bandwidth broker. Flows 
are assigned by the PIB, allocating bandwidth that is requested. Priority is assigned via 
flow DD’s. 


2. SAAM Routers 

SAAM Routers are similar to local traffic controllers. Best effort traffic may enter 
the Information Superhighway without any QoS guarantee. Traffic that requires a 
performance guarantee will have to be admitted by the routers. The routers look to the 
server for approval. 

B. AUTHENTICITY REQUIREMENTS 

In the context of communications across a SAAM network, the following attacks 
can be identified: 
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1 . 


Disclosure 


Disclosure is the release of message contents to any person or process that does 
not have the appropriate cryptographic key. An adversary could potentially re-route all 
traffic to a node where they have root access. 

2. Traffic analysis 

Traffic analysis is the discovery of the pattern of traffic between parties. 
Protection from traffic analysis is not addressed by the security in this thesis. 

3. Spoofing 

Spoofing is the insertion of a message into the network by a fraudulent source. 
SAAM is particularly vulnerable to a spoofing attack because of the use of mobile code. 
The security protocol for SAAM should prevent spoof attacks. 

4. Content modification 

Changing the contents of a message, including insertion, deletion, transposition 
and modification of bits and characters, is content modification. 

5. Sequence modification 

Sequence modification includes any modification to a sequence of messages 
between parties, including insertion, deletion and reordering. 
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6. Timing modification 


Timing modification includes delay or replay of messages. One technique in 
common use on the Internet today is to overcome security systems by capturing the bit 
stream, storing it for later use and then replaying the bit stream to gain access. SAAM 
should have an anti-replay function in the security system. 

7. Non-Repudiation 

Non-repudiation is the ability to prove that a person has made a transaction. 
Repudiation is not an issue in SAAM security because this security concerns machines 
and software only. 

8. Scalability 

SAAM is a scalable system, using a hierarchy of servers that is similar to domain 
name system (DNS). Security should not violate scalability. 

C. PROBLEMS WITH SECURITY 

Consider two inherent problems with security, brittleness and scalability. 

1. Brittleness 

All nodes can be secured with one global key that is the same throughout the 
enterprise. However, a compromise anywhere is a compromise to the whole enterprise. 
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2. Scalability 


All nodes can be secured by using pairs of keys for each session. This overcomes 
brittleness because the compromise of any one node would not harm the rest of the 
system. An exception to this is the central KDC in Kerberos, but the KDC is assumed to 
be physically secure. The problem with using session key pairs is scalability as described 
below. 

Any security scheme that uses a shared secret assigns a session key for each 
connection in a network. Each pair of nodes shares a pair of symmetric keys. As 
demonstrated in the graph below, the number of sessions that can occur in a 4-node 
network is only six sessions. That is, six key-pairs must be present in this network. 


6 Sessions in 4 Node Network 



Figure 2. Six Sessions Are Needed For a Four-Node Network 
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Given 5 nodes, there must be 10 sessions. Given 6 nodes, there must be 15 
sessions. The mathematical relationship between the number of nodes and the number of 
sessions is as follows: 

N = number of nodes 
S = number of sessions 
S = (N * (N-l)) / 2 

As the number of nodes increases linearly, the number of sessions increases at a much 
faster rate. 


Combinatorial Explosion 



Number of Nodes (N) 


— E— S 




Figure 3. Combinatorial Explosion 

The problem with combinatorial explosion is the management of so many keys. 
Given that the maximum number of nodes on one SAAM active site is 40, there will be 
780 sessions. 
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D. REASONS FOR KERBEROS 


Kerberos is used during phase one of the protocol, which establishes machine-to- 
machine authentication only. Kerberos was developed to protect remote logins from 
students across an untrusted network. SAAM routers will be logging into the SAAM 
Active Site over an untrusted network. We chose Kerberos because it was ideally suited 
to protection from eavesdropping on the network. SAAM requires authenticity but not 
confidentiality to avoid overhead. 

How we chose Kerberos is interesting to note. We began with a simple matrix to 
compare several security schemes against each other. A decision support software tool 
was then used to try to quantify the utility of each authentication system, and to rank the 
best alternatives. 

Ranking for Best Authentication Goal 
Alternative Utility 

Kerberos 0.795 I i 

IPsec 0.588 I I 

SSL 0.565 I I 

S/MIME 0.554 I I 

CA 0.545 1 I 

PGP 0.530 I I 

MTTL 0.205 I 1 

Preference Set = Authentication Mechanisms in SAAM 

Figure 4. LDW result - Ranking for Best Authentication 

Finally, we discovered that the authors of rfc2747 were faced with the same 

decision to find an authentication scheme for a distributed protocol. They also chose to 
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use Kerberos. For more information on how we chose Kerberos, please refer to the 
appendix entitled "Selecting and Authentication System." 

E. OUR SETUP 

Our solution avoids both the brittleness and scalability problems. The authenticity 
protocol is comprised of two phases. Phase one of SAAM security will use Kerberos. 
Kerberos will establish a trusted session between two nodes, using a Trusted Session Key 
pair. The use of session key pairs avoids the brittleness problem, but does have the 
scalability problem. 

To overcome this scalability problem, SAAM will use a global key that is valid 
for a very short period of time. This global key is called the SAAM recognition key. In 
that way, Trusted Session Key pairs are kept to a minimum. Only a single recognition key 
is active at any one time, independent of the number of nodes. 
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Single Recognition Key 



Figure 5. One Global Recognition Key Independent of Number of Nodes 
The global key does, however, have the brittleness problem. The brittleness 
problem is addressed by periodically refreshing the global key. A table of keys will be 
distributed periodically, and all routers will authenticate with each other by stepping 
through the table of keys. 

The timing of this step will be an important issue to solve. The length of time that 
one key can remain secure must be less than the length of time that the key could be brute 
force cracked. In the case of a one-way hash algorithm, such as MD5, the key shift 
should occur every two minutes. Network timing protocol (NTP) is accurate to 
milliseconds and may be the best way to solve the timing-jitter problem. How to keep 
this time in synchronization will be explored. 
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IV. DESIGN 


A. CHAPTER SUMMARY 

This design chapter is organized into five major parts, beginning with the 
introduction. The major assumptions portion explains what assumptions were made to 
make this protocol a reality. The functions of the authentication protocol are detailed in 
this chapter. Three different scenarios are identified where SAAM will need to use the 
authentication system, and these scenarios are described in detail, using timing diagrams. 
The interactions between the classes are described, using UML-like diagrams. Finally 
diagrams of packet structures are provided. 

1. Definitions 

The following definitions describe the state of a node: 

New Node - A new node is untrusted and unrecognized. A new node is different from an 
intruder because a new node shares a node secret with the KDC. 

Trusted - A node in the trusted state has a Trusted Session Key with a node that is 
recognized in place. A trusted node has a session with an already recognized node. A 
trusted node is not necessarily recognized. 

Recognized - A recognized node will have the SAAM key table in place and actively 
working. The Recognition Key is active in a recognized node. 

Invalid - A node that has no node secret. For example, a node that has been captured by 
the enemy is removed from the SAAM network by revoking the node secret from the 
KDC. 
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The following definitions describe the key types. 


Node Secret - K This is the long-term key that is in place before any traffic runs over the 
net. In Kerberos terminology, the node secret is called the secret key. This node secret is 
shared between the KDC and node i. 

A 

Trusted Session Key -k M This is the final Kerberos session key shared between node i 
and node j. In Kerberos terminology, the Trusted Session Key is called the session key. 
Each realm will have a maximum of 40 Trusted Session Key pairs. 

Recognition Key - k [ ] This is the active SAAM session key inside the Recognition Key 
Table throughout the SAAM active site. 

The following definitions describe the message types with Java class names. 
JoinRequestiava - A message sent when a new node wants to gain the Trusted Session 
Key. The JoinRequest message is used before Kerberos begins. This message goes from 
an untrusted New Node to a trusted neighbor. 

TrustedSessionRequest.iava - This message goes from a Recognized Node to the KDC. 
This class is an abstraction of all the messages that the Kerberos protocol sends in order 
to gain the Trusted Session Key. The TrustedSessionRequest message is used to begin 
the actual Kerberos traffic. 

TrustedSessionResponse.iava - This message goes from the KDC to a Recognized Node. 
Again, this class is an abstraction of the messages within the Kerberos protocol. It is 
important to note that the TrustedSessionReponse message does not show the full 
Kerberos Trusted Session Key distribution. In Kerberos, the ticket is relayed to the target 
host, along with an authenticator. Mutual authentication occurs when another 
authenticator is sent from the target to the trusted neighbor. Kerberos provides some 
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security against reply attacks by using a time stamp within the authenticator. 
TrustedSessionResponse is hiding all of this traffic from SAAM. 

KeyTableRequest.iava - A message sent to gain the Recognition Key Table. This 
message goes from a trusted and unrecognized node to a Recognized parent. 

KevTableResponse.iava - A message that contains the Recognition Key Table encrypted 
with the Trusted Session Key. This message goes from a Recognized parent node to a 
child node that has just become recognized. 

TimeResponse.iava - A message that synchronizes the time from parent to child. This 
message goes from a recognized node to another recognized node. 

B. MAJOR ASSUMPTIONS 

1. First Key Already in Place 

The very first long-term key, called the Node Secret in this authentication 
protocol, is crucial to the subsequent distribution of all other session keys. The first key 
must already be in place before the authentication protocol begins. No matter what 
mechanism is chosen, interaction from a human being will be required at some point. 
Some possible implementations of first key distribution include PKINIT, PKI, SecurelD 
card, Smart card, Certificate Authority, and hardcoded secret from factory in EPROM. 
For the purposes of this thesis, it is assumed that the node secret is hard coded from the 
factory in an EPROM chip. 
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2. Time Sync on Kerberized Hosts 

It is assumed that the BIOS clocks on the SAAM routers are reasonably close to 
each other before Kerberos sends authenticator messages, which are based on time. The 
time sync messages in the authentication protocol are sent after Kerberos, and just after a 
node becomes recognized. 

3. KDC is Physically Secure 

The Kerberos Key Distribution Center must be secure in order for Kerberos to 
function. It is recommended that all unneeded tcp and udp ports be blocked to and from 
the KDC. In addition to software controls, the KDC should be physically locked in a 
closet to prevent physical access. 

4. Proactive Key Refresh 

It is assumed that the SAAM authentication system will know when keys are 
about to expire and take action to refresh those keys before expiration. Kerberos does 
this automatically. The code for the Recognition Keys will have to include intelligence to 
do a proactive Recognition Key Table refresh. 

5. Mutual Authentication 

It is assumed that mutual authentication will always be used in this protocol. 
Mutual authentication means that both the kerberized hosts are authenticated to each 
other. For example, RouterA wants to talk to a target, RouterB. RouterA obtains a ticket 
from the KDC and passes the ticket plus an anti-replay authenticator to RouterB. At this 
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point, RouterA is authenticated to RouterB because only the trusted KDC could produce 
this ticket. RouterB, the target, replies to RouterA with another authenticator message 
encrypted with the Kerberos session key. Thus, the target is authenticated to the 
requestor. 

C. AUTHENTICATION PROTOCOL FUNCTIONS 

The authentication protocol performs the following high level functions: (1) first 
long term key distribution, which is called the Node Secret distribution in this document, 
(2) router to router authentication with Kerberos, (3) generation of Recognition Key 
Table, (4) encryption and distribution of Recognition Key Table, (5) secure time 
synchronization, and (6) authenticated SAAM signaling traffic. 

1. Node Secret Distribution 

The first key is already in place, as discussed in the major assumptions. 

2. Machine to Machine Authentication 

Kerberos is the chosen protocol for machine-to-machine authentication. In 
addition to authentication, Kerberos protects against replay attacks to some degree. 

a. Kerberos Box Model 

We used the Kerberos Box model developed by Brian Tung in his book, 
Kerberos. During our thesis brief, this was a standing model with written messages, 
cardboard boxes, locks and keys to represent encryption throughout the Kerberos 
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protocol. This live demonstration solidified our understanding of Kerberos. The function 
of tickets and authenticators was made very clear. 

The basics of Kerberos are that when Alice wants to talk to Bob, Alice 
first requests for permission from the KDC. The KDC grants a session key for the 
conversation between Alice and Bob. How this session key is distributed securely in 
interesting. The KDC encrypts one session key with Alice’s long-term key. Then the 
KDC encrypts the other session key with Bob’s long-term key. This second message is 
called the ticket. The two messages are sent to Alice. Alice can decrypt the first session 
key with the long-term key. She cannot decrypt the ticket. Alice checks the time on her 
watch, writes the time in a message, and encrypts the message with the session key. This 
message is called the authenticator. Alice sends the ticket and authenticator to Bob. 
Immediately, Bob cannot open the authenticator, but he can open the ticket with his long¬ 
term key. Bob decrypts the ticket and gains access to the session key. Bob then uses the 
session key to open the authenticator. If the time from Alice is within a 5-minute 
window, then Bob trusts Alice. Bob then makes his own authenticator and sends it to 
Alice. Mutual authentication takes place to prevent replay attacks from Bob or Alice’s 
packets. 

The box model idea was extended to include the entire SAAM 
authentication protocol. Step one is Kerberos and step two involves the Recognition Key. 

b. Win2K Kerberos Action Diagrams 

The Kerberos activity inside of Windows2000 is shown below in the form 
of action diagrams. 
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ACTION DIAGRAM 

Authentication with Kerberos on Win2K 


Msg I - Client to KDC 
Authentication Service Exchange 
Once per user logon session. 
KRB_AS_REQ 


KRB„AS_REQ msg parts: 

I n 

Alice, TGS Kalice(Alice, time) 

userid, svc name Kuser (user, time) 

“Alice wants TGS" Preauthenticated data 



ACTION DIAGRAM 

Authentication with Kerberos 

Msg 2 - KDC to Client 
Authentication Service Exchange 
Once per user logon session. 

KRB_AS_REP 


KRB_AS„REP msg parts: 

1 n 

Kalice TGT 

(useSaliceforT GS) Ktgs 

(use Salice for alice.) 
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ACTION DIAGRAM 

Authentication with Kerberos 


Msg 3 * Client to TGS KRB_TGS_REQ msgparts: 

Ticket Granting Service Exchange I II m 

Once per type of service Alice wants Bob. Salice{ Alice,time} TGT 

KRB_TGS_REQ User Name: Alice Salice is Alice’s long term Ktgs{use Salice for Alice} 

Bob is the name of service for key. 
which user wants a ticket. Authenticator is User- 

name, time}. 

1 2 3 4 5 6 



ACTION DIAGRAM 

Authentication with Kerberos 


Msg 4 - TGS to Client 
Ticket Granting Service Exchange 
Once per type of service 
KRB_TGS_REP 


KRB_TGS_REP msg parts: 

I n 

Salice(uses Sab for Bob). ticket 

Kbob (usesSab for Alice). 
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Msg 5 - Client to Server 
Client Server Exchange 
Once per service session 
KRBJTGSJREQ 


ACTION DIAGRAM 

Authentication with Kerberos 

m 

flag 

Does Alice want mutual 
authentication from Bob? 


KRB_AP_REQ msg pans: 

I n 

Sab{Alice,time} ticket 

Authenticator encrypted with obtained from TGS Ex- 

the session key for the service, change. 
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ACTION DIAGRAM 

Authentication with Kerberos 


Msg 6 - Server to Client 
Client Server Exchange 
Once per server session. 
KRB_AP_REP 


KRB_AP_REP msg parts: 
I 

Sab {time} 


-note that mutual authentication is optional. 


23456 7 89 

tiii i i i 



31 



ACTION DIAGRAM 

A UTHENTICA TION WITH KERBEROS 


Step 7 - Server and Client talk. 


1 2 3 

1 1 . » 


4 5 6 7 8 

I — 1 I t 


Figure 6. Action Diagram of Kerberos. 
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User logs off and credentials cache is flushed. 



c. 


SSPI 


Windows2000 provides an API to call Kerberos, called the Security 
Support Provider Interface. By using this API, applications can be Kerberized. This API 
requires function calls in C code. 

There are five different ways that Java can call Kerberos in Win2K, as 
shown below. This figure and the following text is a direct quote from the Microsoft 
white paper, The Security Support Provider Interface (SSPI). This is an Operating 
Specific description, focusing on one computer. Note that it is not inherently network 
centric and does not describe the bits on network. 



Figure 7. SSPI and the Windows NT Security Model 

The figure above shows the options available to application 
developers for building distributed applications. The SSPI provides an 
abstraction layer between application-level protocols and security 
protocols. The following are some of the ways to use SSPI services: 

• Traditional socket-based applications can call SSPI routines directly and 
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implement the application protocol that carries SSPI security-related data, 
using request and response messages. 

• DCOM applications provide the best level of integrated security features. 
Applications can use DCOM to call security options, which are 
implemented using authenticated RPC and SSPI at lower levels. 
Applications do not call SSPI APIs directly. 

• WinSock 2.0 extends the Windows Sockets interface to allow transport 
providers to expose security features. This approach integrates the SSPI 
security provider into the network stack and provides both security and 
transport services through a common interface. 

• Winlnet is an application protocol interface that is designed to support 
Internet security protocols, such as Secure Sockets Layer (SSL), over 
Internet protocols. The implementation of Winlnet security support uses 
the SSPI interface to the Secure Channel (Windows NT implementation of 
SSL) security provider. From Ref. [MS White paper] 

d. C code 


Expertise in C code is needed to call Kerberos functions, 

e. JNI 

The SAAM prototype is written entirely in Java. In order for SAAM to 
use Kerberos, Java must call C code functions. The link between these two different 
languages is Java Native Interface (JNI). Expertise in JNI is needed. 

/. Java 

Java expertise is needed because the SAAM prototype is written in 

SAAM. 

g. Other Sources of Kerberos 

(1) MIT provides source C code for Kerberos from their web site. 
Since this Kerberos is also written in C, expertise in C, Java and JNI is still needed. 


34 






(2) University of Illinois provides some beta source code, which is 
a Java wrapper for the MIT C Kerberos. We did not try this code for this thesis, though it 
is important to note that this wrapper exists. 

(3) JCSI is another Java version available from the following web 
site: http ://securitv.dstc .edu. au/proiects/i ava/release3 .html . JCSI is another Java wrapper 
for MIT’s Kerberos. 

h. Generation of Recognition Key Table 

The Recognition Key table is generated using SQL Server. 

The Recognition Key table is generated while Kerberos is running. These 
two events can run in parallel. The Recognition Key Table is distributed upon SAAM 
network boot-up, and then every 24 hours at midnight. 

i. Encryption and Distribution of Key Table 

The Trusted Session Key is used to encrypt and Recognition Key table. 
There is a c function available in the SSPI called EncryptMessage() that should work. 
This encrypted object is then sent to destination nodes. 

j. Secure Time Synchronization 

Secure Time Synchronization will be carried out after a node becomes 
recognized. The time synchronization message is appended with the KeyTableResponse 
message. Time resolution to the millisecond is required, not necessarily microsecond 
resolution. 

The external time source can be any time server, such as the US Naval 
Observatory time server over the Internet using NTP. Another option is to use a hardware 
clock attached to the primary SAAM server. External clocks are sometimes used to 
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prevent the time from being changed covertly. At the very least, the human eye could 
catch that the time has been altered. Another option for the time source is the native 
windows 2000 time service. There are several ways to synchronize time. 

k. Authenticated SAAM Signaling Traffic 

Once the recognition key tables are in place, the sender and receiver have 
synchronized time because of the time sync message that arrived with the recognition key 
table. Based on the time, the sender selects a key to sign the signaling message. Based 
on the time, the receiver is likewise ready to authenticate the message with the same 
recognition key. Recognition keys are symmetric. The sender uses the recognition key to 
run a hash algorithm on the message. The MD5 hash algorithm may be used for 
demonstration purposes. In the final deliverable protocol, a hash algorithm that is more 
secure than MD5 should be used. The output of the hash function is the message 
authentication code (MAC). 

The sender then formats the packet for transmission as follows. 

Key-prefix MAC Message 

The key prefix field is placed in the header to optimize performance on the receiver. The 
receiver has the recognition key in memory, along with the associated key-prefix. The 
receiver begins to read the packet before the entire packet is buffered. The Key-prefix is 
checked before any CPU cycles are devoted to the hashing. If the key-prefix does not 
match the expected value, the packet is dropped. This is a fast reject technique to reduce 
overhead. If the key-prefix does match the expected value, then the receiver performs the 
hash function. If the MAC produced on the receiver matches the MAC in the packet. 





then this packet is authenticated. SAAM continues to process this signaling message. If 
the MAC’S do not match, then the message is discarded. 

D. AUTHENTICATION SCENARIOS 

Authentication in SAAM will happen in three distinct scenarios. They are (1) 
nascent network, (2) New Host joins SAAM Active Site, (3) Key Table change. The 
following diagrams demonstrate these three scenarios. 
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Nascent Network Scenario 



Out of Band 


KDC 


SAAM Server 


Figure 8. (a) Topology of Nascent Network Scenario 


Assumptions: 

1. Svr asks itself am I secure or 
unsecure SAAM, and decides 
secure. 

2. Svr knows how to reach the KDC. 

3. KDC is running Kerberos KDC 
and Recognition Key Table Generator. 


KDC + 

Recognition Key 
Table Generator 


SAAM Svr 



State of 
Svr 



Figure 8. (b) Timing Diagram of Nascent Network Scenario 


Figure 8. Nascent Network 
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When a new SAAM network is bootstrapped two hosts are concerned with 
authentication, the KDC and the first SAAM server. The ServerAgent module on the 
SAAM server must ask the question - will I start a secure or unsecure Active Site? 

Note that we could make a security flag in the DCM message to allow the net to 
become secure on the fly. The net could be in an unsecure state, and move up to a secure 
state. That way, only the primary server has to make this security decision. The primary 
server could also decide to move the network down to an unsecure state in the very next 
DCM cycle. 

The decision for secure AS is made. The second question is how will the server 
reach the KDC. There are several options, including (1) hard coding the IP address into 
the SAAM server, or submitting a host name in a configuration file that an administrator 
can edit before bootstrap, (2) directly connect the KDC to the server, and (3) use a 
traditional routing discovery protocol such as OSPF. The server is in an untrusted, New 
Node, state at this point. 

The KDC is running two software modules. One is the Kerberos KDC, and the 
other is the Recognition Key table generator. 

The SAAM Server sends a TrustedSessionRequest and the KDC responds with a 
TrustedSessionResponse. At this point, the Kerberos Trusted Session Keys are in place 
between the two hosts and machine-to-machine authentication is complete. The server 
sends a KeyTableRequest message to the Key Generator. The Key Generator encrypts the 
Recognition Key table using the Trusted Session Key, and sends this encrypted 
Recognition Key table to the server. At this point the server is in a recognized state. 
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2. New Host Join Scenario 



Figure 9. (a) Topology of New Node Join Scenario 


KDC SAAM Svr RirA RtrB 




Figure 9. (b) Timing Diagram of New Host Join Scenario 


Figure 9. New Host Join Scenario 







A Downward control message initiates the process. A new node router platform 
will wait until it receives the incoming DCM message from the network. This DCM 
message will not be authenticated since the new node does not have the recognition Keys 
of the day within its volatile memory. Once the DCM has been received the new node 
will send a request to the neighboring unit via a JoinRequest message. This message will 
go to the neighboring node where the neighboring node then forwards the message along 
to the KDC. 

It is necessary to send the JoinRequest message to the neighbor rather than 
straight through to the KDC because the SAAM prototype does not yet route best effort 
traffic. That is to say, all messages in SAAM must have an assigned flow id. Since the 
new node is not yet a part of SAAM, there can be no flow id assigned. The neighbor 
node (Router A) is already active and can send messages with an assigned flow id. 

If Kerberos fails to renew it’s Trusted Session Keys, the Trusted Session Key will expire. 
A router that has an expired Trusted Session Key will also wait until the next DCM 
message arrives to initiate a request to join the SAAM Realm. This will allow the same 
module within the Security Manager to process both cases of either a new Join Router or 
an expired router. In both of these cases the 720 SAAM Keys are non-existent or have 
expired thus demonstrating the flexibility of the SAAM Security Manager to handle both 
cases with the same function calls. 

A Trusted session request message is sent. The neighboring SAAM Router, 
Router A, sends the Trusted Session Request message. The session request message is 
requested on behalf of the SAAM recognized neighbor and the new join router up to the 
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KDC. This message traffic is then is processed via normal SAAM routing, which is flow 
based, up to the master KDC. 

The KDC generates a Trusted Session Key for the new node and requesting 
neighbor. The Kerberos trust mechanism queries its database of long term Node Secrets 
to determine if the new node request is valid. The message request is authenticated since 
it traveled along the SAAM Recognized flow based routing mechanism. [Akkoc] If both 
the requesting neighbor and the new node secret keys are found in the KDC secret key 
ring then the KDC will create a trusted session key that is sent back to the requesting 
router via the SAAM Recognized flow base routing. 

The KDC sends the Trusted Session Key to the requestor, Router A, for a new 
node. In Kerberos, a ticket is an encrypted message that contains the session key. The 
requestor passes this ticket onto the target host, RouterB. The ticket is encrypted with the 
Node Secret Key of Router B. A Kerberos Trust is established between the requesting 
neighbor and the new join router. 

The neighbor forwards the ticket to the New Node. Upon receipt of the messages 
from the KDC, the neighbor will open its message and extract the new session key that 
can only be utilized between the neighbor router and the new node router. At that point 
the neighboring router will send the message that is designated for the new node. The 
message format follows: 

Ticket (Encrypted with New Node - Node Secret [ Trusted Session Key ]) 

The neighboring router will also send along an authenticator. The authenticator is 
a time stamp message encrypted with the newly created session key that only the neighbor 
router and the new join node can decrypt. When Router B decrypts the authenticator, the 
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time on Router B is checked to verify is the authenticator was created recently. If not, 
then it is likely that a replay attack is in effect and the session is discontinued. 

The new node sends a Key Table Request to the neighbor. Router A. The new 
node then receives both the authenticator message and the ticket. The new node decrypts 
and extracts the new Trusted Session Key that is only valid between Router A and Router 
B. 



Figure 10. Router Joins the SAAM Network 
The neighbor sends Recognition Keys to the New Node. Router A now has a 
Kerberos Trust communications link between itself and the new join router. That is why 
Router B is said to move to a Trusted state. The neighbor router will copy its 
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Recognition Keys from its volatile memory location to give to the new join router. First, 
the Recognition Key Table is encrypted with the Trusted Session Key. 

The new node can now authenticate DCM messages. The New node now has the 
recognition keys in volatile memory and can process DCM and forward DCM 
information down its interfaces to any other routers waiting to join the SAAM realm. 
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3, 


Scenario 3. Key Table Change 



Figure 11. (a) Topology of Recognition Key Table Change 

Scenario 


Assumptions: 

1. Recognition is about to 
expire. This inititates at about 
2300, 1 hour before expiration. 

On Svr, SvrAgent knows 
that it is close to expiring, so 
the securityManager is 
triggered. 

2. Each router is responsible to 
Maintain TRUST with its 
Neighbors. 

3. Unsolicited KeyTableResponse 
Is sent from Svr to children. 


KDC SAAM Svr 


RtrA 


State of 
Svr 



Figure 11. (b) Timing Diagram of Recognition Key Table 
Change Scenario 


Figure 11. Key Table Change Scenario 
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E. JAVA CLASS FILE INTERACTIONS 


The OSI model is used here to demonstrate where Kerberos will be implemented 
in the SAAM prototype. Keep in mind the emulated nature of the prototype as shown in 
Yarger and Vrable’s thesis chapter 4 on modeling. Recall that the control executive and 
resident agents are all part of the emulated application layer. The packet factory runs at 
the data link layer, beneath the routing algorithm in the network layer. The emulated 
physical layer contains the translator. This physical layer will also contain Kerberos. 
Kerberos is in the physical layer because our implementation uses the Kerberos, which is 
built into Windows2000. Because Kerberos is in the physical layer, Kerberos can provide 
services to any component in the SAAM prototype, providing flexibility. The figure 
below shows where Kerberos fits in the SAAM prototype, using the OSI model. 


High Level Design 
Kerberos in SAAM 



Figure 12. Emulated OSI model - SAAM Prototype with Kerberos Authentication 









In very broad terms, the entire SAAM system uses the entire Kerberos system. 


High Level Design 1.0 


SAAM 


Uses 


Kerberos 


Figure 13. High Level Design - Level 1.0. 

Both SAAM and Kerberos are more complex systems than the figure above 
shows. Within SAAM, there is the control executive class, which is involved in all 
control traffic, but not involved in data traffic. Regular data traffic, a.k.a. SAAM traffic, 
does not need authentication. Remember that overhead is a consideration when 
implementing authentication. SAAM is concerned with authenticating control traffic 
only. Control traffic is like inter-routing protocols on Cisco routers, which can change 
routing tables. Control traffic is also called signaling traffic. 

The control executive will be kept as small as possible, similar to the principle of 
the micro-kemal in Microsoft’s Windows NT operating system. The Packet Factory is 
another class that all control traffic uses. Adjustments to SAAM will be done in the 
Packet Factory whenever possible. 
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The Security Manager object will take care of all the Kerberos services for 
SAAM. It is interesting to note that the Security Manager is placed similar to the 
DiffServ bandwidth broker. The Security Manager hides the complexity of Kerberos 
from SAAM. The Security Manager will receive authentication requests and return a 
Boolean value, true or false, if the authentication passes or fails. In general, an 
authentication that passes will return control back to the packet factory for continued 
execution. A failed authentication will result in the message being dropped. For testing 
purposes, we will need to be notified when authentication fails with an error message. 
For the real SAAM deployment, no such error messages should be delivered to prevent an 
attacker from gaining any more knowledge about the system. The figure below shows the 
call from the Packet Factory to the Security Manager. 
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High Level Design 2.0 


Packet Factory 


Checks 



Security Manager 

Boolean 1 or 0 


Figure 14. High Level Design - Level 2.0. 

Within SAAM, there are several classes, which communicate with the control 
executive. They are the packet factory, the routing algorithm, the Inbound Interface, and 
the translator. The Security Manager will be added as shown below. 
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High Level Design 2.10 

CLASS DIAGRAM 



Figure 15. SAAM Classes in Contact With the Control Exec 
Each of these classes and their communication with the Control Executive are 
discussed below. 

The Packet Factory builds packets by aggregating the individual message updates 
into a packet and finally appending a header. The new packet is communicated to the 
Control Exec. The packet factory also receives inbound packets and parses the packet for 
messages in the payload. 


50 










High Level Design 2.11 

CLASS DIAGRAM 

Packet Factory Interaction with Control Exec. 



Figure 16. Packet Factory Communicates with Control Exec 
The Packet Factory calls the Security Manager to do the following: 

(1) Authenticate all inbound (mobile code) resident agents before execution. 

(2) Authenticate outgoing code to destination hosts. Authentication of control traffic 
requires the Recognition Keys. 

Further defense can be added to SAAM in the Security Manager. For example, a 
method could instantiate a virus wall (virus vacuum on a bastion host). Some work is 
also in progress to add a packet filter to SAAM. 
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High Level Design 2.12 

CLASS DIAGRAM 

Control Exec, interaction with Kerberos Referee. 



i 

i 


Figure 17. Packet Factory Calls the Security Manager 
Control Exec sends two types of messages to Routing Algorithm: 

(1) FlowRoutingTable updates 

(2) ARPCache updates. 

The packet which was the source of these updates must have been already 
authenticated. The Recognition Key has already been used by this point. If not, then 
send message into the bit bucket. 
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High Level Design 2.13 

CLASS DIAGRAM 


Control Exec interaction with Routing Algorithm 



Figure 18. Control Exec Communicates With the Routing Algorithm 
The Control Exec sends a new scheduler to the outbound interface. A new 
scheduler may help route traffic in congestion state. Again, this new scheduler arrived in 
the form of a resident agent, which must have already been authenticated by this point. If 
the message is not authenticated then the message is dropped. 
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High Level Design 2.14 

CLASS DIAGRAM 


Control Exec interaction with Interface (outbound). 



i 


Figure 19. Control Exec Communicates With the Outbound Interface 
The control exec sends emulation table update messages to the Translator. These 
updates have been parsed out of a packet beforehand, and so the packet must have been 
authenticated. 
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High Level Design 2.15 

CLASS DIAGRAM 

Control Exec interaction with Translator 



Figure 20. Control Exec Calls the Translator 

High Level Design 2.30 



Figure 21. Security Manager Passes Messages with Packet Factory 
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High Level Design 2.3 

Kerberos Referee hides the complexity of Kerberos from SAAM. 



Authentication Service - KDC gives the client a logon session key and a TGT. 

- KDC gives the saam demo station a session key and a TGT. 

Ticket Granting Service - KDC distributes a service session key and a session ticket for the service. 

- KDC distributes a service session key to send a resident agent, and a session ticket for the target router. 

Client/Server - Client presents the session ticket for admission to a service. 

- Demo station presents the session ticket for admission to remotely run a resident agent. 


Figure 22. Security Manager Hides Kerberos Details from SAAM 


F. PACKET STRUCTURE 


The first type of packet is the Encrypted Recognition Key Table. 


Encryption 


Recognition Key 


Figure 23. Packet with Recognition Key Table Encrypted with Trusted Session Key 


The second type of packet is the signed signaling traffic 


Index 


MAC 


Signaling 


Figure 24. Packet With Signed Signaling Traffic 
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V. TIME PROTOCOL 


SAAM requires time synchronization between nodes for two reasons. The first 
reason is that Kerberos requires time synchronization for the authentication process to 
function properly. Without time synchronization, Kerberos is subject to replay attacks. 
The second and most important reason for time synchronization is that the global 
recognition key is identified by the current time. Every two minutes, a new key is used. 
All nodes must have the same clock time in order to use the same recognition key. 
SAAM requires time resolution to the millisecond, which NTP does provide. GPS 
provides time resolutions to the microsecond. 

A. NETWORK TIME PROTOCOLS 

Previous research students at the Naval Postgraduate School (NPS) recently 
researched the Network Time Protocol. [Hensley and Ludden] Their prototype used 
NTP, providing great insight into the applicability of ongoing research and development 
within the SAAM Enterprise system. 

1. Description 

The Network Time Protocol (NTP) is a distributed computer clock 
synchronization protocol. NTP is a standard that is implemented by most major 
Operating Systems, providing a client-server communication hierarchy. 
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B. NTP SYNCHRONIZATION 

NTP uses Universal Time Coordinated (UTC). NTP uses UTC to synchronize 
“primary” servers via radio, satellite receiver or modem. These primary servers then 
adjust the clocks of secondary servers/clients. In order to correctly adjust clocks of 
secondary server over a LAN or WAN, a time offset of the server clock relative to the 
client clock is computer by the client running NTP. In existence today, there are 79 
public primary servers synchronized directly to UTC, located in every continent except 
Antarctica. There are over 100 public secondary servers synchronized to the primary 
servers and providing synchronization to more than 100,000 clients and server in the 
Internet. Additionally, there are an unknown number of private servers utilizing NTP. 
[Ahmad] Brining up another server is very straightforward. 

C. NTP CLOCK SYNCHRONIZATION 

The general model for discovering the clock offset starts with a server sending a 
message that includes its current clock value to the client, which could be another server 
or workstation. The client records its own current clock value upon arrival of the 
message. For accuracy, the client has to measure the server-client propagation delay. 
NTP measures the total roundtrip delay and assumes the propagation times are 
statistically equal in each direction. [Hensley and Ludden] 

Clock errors are due to variations in network delay and latencies in computer 
hardware and software (jitter), as well as clock oscillator instability (wander). According 
to NTP documentation, NTP in the majority of cases can keep clock synchronization 
within a few milliseconds on LANS and a few tens of milliseconds on WANs. [Hensley 
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and Ludden] This performance may be acceptable for the target integration-testing phase 
of SAAM. 

NTP does not have well established security. The current security in NTP 
addresses statistical attacks and does not address attacks from a malicious attacker. For 
example, an attacker can delay time messages so that a target host will get the wrong 
time, forcing the clock to skew. One idea to prevent this type of malicious attack is to 
make every host synchronize with a Global Positioning System (GPS) satellite. An 
antenna would be connected to every computer. This design will prevent the malicious 
attacker from skewing the clock. 

D. NTP IMPLEMENTATION IN SAAM 

SAAM Enterprise implementation of NTP would constitute the following 
overview strategy. A standalone dedicated time server module would be designated as 
the master timeserver for the SAAM Enterprise. This master server can be a cluster to 
prevent a single point of failure. The Server NTP time module once incorporated into the 
SAAM architecture can a be a feature that is enabled by default if it is the only Router 
within a SAAM Enterprise configuration. This SAAM Server would also be default be 
its own Kerberos Distribution Center (KDC) if no other SAAM Servers or Routers are 
available on the Network. Follow on SAAM Servers or Routers then joining the SAAM 
Enterprise would listen for a broadcast time or unicast time protocol message from the 
existing KDC/NTP Server. Once the discovery of a master timeserver has been 
established then the clock synchronization process would immediately take effect as 
described in paragraph C. NTP CLOCK SYNCHRONIZATION. 
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E. WINDOWS TIME SYNCHRONIZATION SERVICE 


Windows 2000 (Win2K) uses a time service, known as Windows Time 
Synchronization Service (Win32Time), to ensure that all Win2K computers on your 
network use a common time. In fact, MIT Kerberos 5, Win2K’s default authentication 
protocol, requires the service. In Win2K, time synchronization is crucial because 
Kerberos uses workstation time as part of the authentication process. Let’s discuss the 
time service, which complies with the Simple Network Time Protocol (SNTP). (For more 
information about SNTP, see Request for Comments— RFC—1769.) [Ahmad] 

F. IMPLEMENTATION 

When a client workstation (i.e., a Windows 2000 Professional—Win2K Pro— 
machine) boots, it contacts a domain controller for authentication. When the two 
computers exchange authentication packets, the client adjusts its local time based on the 
target (i.e., the domain controller's) time. If the target time is ahead of local (i.e., the 
client's) time by less than 2 minutes, the client immediately adjusts its time to match the 
target time. If the target time is behind the local time by less than 2 minutes, the client 
slows its clock over a period of 20 minutes until the two times are in synch. If the local 
time is off by more than 2 minutes, the client immediately sets its time to match the target 
time. 

Because time synchronization is so critical, the client periodically verifies that its 
time is in synch with the timeserver. By default, the client performs these checks every 8 
hours. It connects to the authenticating domain controller, which is its inbound time 
partner, and performs the checks using a strategy that seeks to attain a convergence 
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wherein the two computers are never more than 2 seconds apart. If the local time strays 
by more than 2 seconds, the client checks its time against the authenticating domain 
controller more often—in fact, it divides its verifying interval in half, repeating this 
division until it meets one of the following conditions: 

The difference between the local and target is no more than 2 seconds 
-The interval reaches its shortest duration (by default, 45 minutes) 

-When the two computers' times return to within 2 seconds of each other, the verification 
interval doubles at each check until reaching the maximum interval of 8 hours. [Ahmad] 

The reader may notice that the time resolution of 2 seconds is much rougher than 
the millisecond resolution provided by NTP. 

Note that the SAAM prototype has a scaling factor of about 300:1. For every 300 
seconds of prototype operation, a real router could do in about 1 second. 

G. TIME SERVICE HIERACHY 

Windows Time Synchronization Service uses a hierarchical relationship that 
focuses on the PDC Emulator at the root of the Active Directory (AD) forest. By default, 
the first domain controller in a forest acts as the PDC Emulator for the root domain and 
becomes authoritative for the entire enterprise—an event that the Event Viewer logs in 
the system log as Event ID 62. You’ve probably seen the Event Viewer filled with Event 
ID 62 from the source Win32Time. The description field states, "This Machine is a PDC 
of the domain at the root of the forest. Configure to sync from External time source using 
the net command, ‘net time /setsntp:<server name>\" In other words, you must configure 
the PDC Emulator to recognize an external SNTP timeserver as authoritative using the 
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Net Time command from the command prompt. Type in the following at the command 
prompt for the syntax, 
net time /? 

You can use any of the following US Naval Observatory SNTP timeservers: 

• tick.usno.navy.mil at 192.4.41.40 

• tock.usno.navy.mil at 192.5.41.41 

• ntp2.usno.navy.mil at 192.5.41.209 

Let’s look at the time service hierarchy from the bottom up to see how computers 
synchronize times and dates with their time partners. Workstations and member servers in 
a domain use the authenticating domain controller as their inbound time partner. Domain 
controllers use the PDC Emulator in their own domain as their inbound time partner. The 
PDC Emulator in each domain uses the PDC Emulator in its parent domain as the 
inbound time partner, until we reach the top of the hierarchy—the root domain. The PDC 
Emulator in the root of the forest is the authoritative time server, which you should set 
manually to synchronize time with an external SNTP time server, as discussed earlier. 

One final note: SNTP uses UDP port 123 by default. If you want to synchronize your 
timeserver with an SNTP server on the Internet, make sure that port is available. [Ahmad] 
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VI. PROTOTYPES 


A. SAAM INTEGRATED PROTOTYPE 

This prototype was implemented with Jerome Brock and Joel MacRitchie. The 
SAAM software code version used was SAAMvl.OMay2000. This code contained the 
integrated modules of previous thesis students, and was optimized by Cary Colwell. This 
code was noticeably much faster than the code in use last December. 

1. Topology 

There were four machines used in the topology, a KDC, Bravo, Charlie and a 
sniffer. We were focusing only on the communication between a Recognized SAAM 
router with a New Node SAAM Router. A SAAM Server was stood up but not used in 
our testing. The SAAM server was essentially an extra PC. The standard SAAM demo 
code of one Server and 2 Routers was used. 

2. KDC 

The Kerberos Distribution Center (KDC) ran MIT’s KDC distribution code. The 
KDC ran on Linux. The physical PC was down in the laboratory in Span-238. Most of 
the other testing occurred in the lab upstairs in Span-525. The KDC was stable over 
several days, serving Kerberos tickets without need for a reboot. 

One of the reasons that the KDC was installed downstairs was that we ran out of 
drive space on our Netl network upstairs. A new 15GB hard drive was purchased and 
used in the KDC downstairs. This was plenty of room. 
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3. 


JCSI Code 


JCSI is Java code that implements Kerberos for clients to request Kerberos 
sessions from the MIT KDC. JCSI was chosen because it is native Java, just like the 
SAAM prototype. The JCSI code implements the GSS-API, which is an open standard 
API, designed for Kerberos. There are two parts to a Kerberized host, the client service, 
and the server service. Please notice that the Kerberos server service is completely 
distinct from the KDC. 

a. Kerberos Client 

The JCSI Kerberos client is the Kerberos principle that initiates the 
security session. For example, in the New Join Scenario, RouterA would invoke a 
Kerberos client just after receipt of the JoinRequest message from RouterB. 

In our prototype, the JCSI Kerberos client code ran on 
Charlie.netl.cs.nps.navy.mil. In addition, the client also ran on the PC in the Span-221 
classroom during our presentation, for a live demo. 

b. Kerberos Server 

The JCSI Kerberos server is the Kerberos principle that receives the 
security session. The server is sometimes called the target principle. For example, 
RouterB would run the server in the New Join Timing Diagram. In our prototype, the 
JCSI Kerberos Server was running on Bravo.netl.cs.nps.navy.mil. Ultimately, the client 
and server were just another object instantiated by the SAAM Translator. 
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4. 


Security Manager 


The Security Manager was a class in the saam.security package. The Security 
Manager effectively instantiated the Kerberos client or server, based on input from the 
Packet Factory. A boolean value passed into the Security Manager constructor is parsed 
to switch between a server or client. The Packet Factory instantiates the Security 
Manager. 


5. Packet Factory 

We found a spot in the Packet Factory to input the constructor for the Security 
Manager. No more logic was added for our prototype, yet. 

6. Packet Sniffer 

Once the Kerberos Client was instantiated, the client immediately communicated 
with the KDC, running the first two Kerberos protocols of Ticket Granting Service (TGS) 
and Authentication Service (AS). The Client Server (CS) Kerberos protocol began when 
Charlie (the client) communicated with Bravo (the server). Our topology also included a 
packet sniffer to capture the packets going between these two. 

We hard coded a message to represent the Recognition Key Table, for lack of time 
to get a real key table. The message read "This is the key table." When encryption was 
not selected in the code, we were able to see that string in a packet. When encryption was 
selected, the string was encrypted. The switch is a boolean value passed into the 
constructor for the Security Manager. 
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7. Issues 


After implementing this prototype, we discovered some major issues that still 
need to be overcome to fully implement the SAAM authentication protocol. 

a. Key Tab File Distribution 

The JCSI server requires a key tab file to be on the local c drive. In the 
prototype, Bravo (the server) already had a key tab file on the c drive. Automatic 
Kerberos session setup for a new host will now face the difficulty of getting the key tab 
file in place, if JCSI is used. Windows 2000 may be storing the key tab information in 
the local registry, but any lookup was invisible to us when we tried Windows 2000 
Kerberos. 


b. Security Manager Behavior 

The Security Manager in our prototype was very basic. The full behavior 
of the SAAM authentication protocol still needs to be implemented. 

B. SUPPORTING PROTOTYPES 

The prototypes developed can be categorized into two groups, phase one and 
phase two. Phase one implemented Kerberos, distributing a Trusted Session key to the 
Kerberos client and server hosts. 
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1 . 


Phase One Prototypes 


Three different prototypes made Kerberos usable by SAAM. One used Java and a 
batch file in Windows 2000, the second used C code and called the SSPI in Windows 
2000, and the third was an effort to use Java with JCSI on MIT’s Kerberos. 

a. Windows 2000 

Windows 2000 relies on Kerberos realms for authentication. Kerberos is 
only used with domain logon to Active Directory, that is, only used when there is a logon 
over the network onto a Windows2000 server. Kerberos is not used for local logon. 

We implemented a Windows2000 Domain using Windows 2000 
Advanced Server. Advanced server offers some extended features for Microsoft Back 
office that we did not use. Windows 2000 Server would also work. 

When a host logs onto Win2K Server, the Server tries to authenticate with 
Kerberos. If that fails, then the Server tries to use LAN Manager (LanMan) for 
authentication. When we installed this OS, we chose to not install NETBIOS because we 
did not want to allow any hosts to log on without using Kerberos. We chose to not be 
backward compatible. 

(1) Java. A simple Java chat program was adapted from Deitel 
and Deitel’s Book, Java How to Program. In this prototype, buffaloberry was running the 
chat client and saamwks2 was running the chat server. In the Java code, the line before 
opening the socket, we forced the KDC to issue a ticket for the target server. How this 
was done was rather brute force. Java called a batch file, which issued a net use 
command to map a drive from buffaloberry to saamwks2. The OS took care of issuing 


67 




Kerberos credentials when the drive was mapped. The credentials cache on buffaloberry 
indeed showed that a ticket for saamwks2 had been issued. We examined the credentials 
cache using a tool called klist.exe from Microsoft. This prototype effectively forced a 
Kerberos session to be opened, but was not quite the intricate control we had in mind for 
SAAM. 

(2) C code. The SSPI provided function calls to get to 
Kerberos in Win2K. We were able to adapt the SSPI code that is freely available from 
the following web site: 

http://msdn.microsoft.com/library/default.asp ?URL=/library/psdk/secspi/sspiref_OOoj.htm 
Open the table of contents to the following sample code: 

MSDN Library\PlatformSDK\Security\LogonAuthentication\Security Support Provider 
Interface\Using SSPI\Sample SSPI Code. 

After several days of debugging, we finally got this code to work. 

The Server code had to be running. The client code could not call 
the server’s OS, but actually needed to have server code. Once the two applications 
established a socket, Kerberos was used. A ticket was issued and a short session was 
established and closed. Once again, etherpeek revealed that Kerberos was indeed being 
called and sent encrypted packets. 

A major problem with this prototype was how to pass messages 
from C to Java. Java Native Interface (JNI) was the method attempted, but we could not 
get it to work. The complexity of C, followed by the complexity of type marshalling 
literals through the JNI barrier was a problem that proved to be non-trivial. Given 
expertise in C, JNI, and Java, this code should certainly work. One drawback to using the 
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Windows 2000 was lack of platform independence that the current SAAM prototype 


enjoys with Java. 

2. Phase Two Prototypes 

Once we could establish a shared Trusted Session Key, the remaining part of the 
authentication protocol was prototyped. A Recognition Key Table was generated and 
distributed with the following prototype. 

a. Web Recognition Key 

SAAM SERVER AM) KDC 



|7Y028D5W1744 ” 3 

S.A.A.M. 2 Master Router KDC Update 


SAAM SERVER AND REGIONAL ROUTERS 

SAAM SERVER AND REGIONAL ROUTERS 





17Y028D5W1744 jj 

S.A.A.M. 2 Master Router KDC Update 

(7Y028D5W1744 3 

SA..A.M. 2 Master Router KDC Update 

|0E331X0L8161, False 3 

|0C458C6M8742, False Vj 

S.A.A.M. Router to Router KDC Update 

S.A.A.M. Router to Router KDC Update 


Figure 25. Web Recognition Key 

The prototype demonstration for the key distribution table was constructed 


with the following devices: 

a. Windows 2000 Server 

b. Internet Information Server (IIS 5.0) 
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c. Microsoft SQL v 7.0 Server 

d. Active Server Page (ASP) 

e. Java Scripting 

f. Secure Socket Layer (SSL) 128 bit encryption 

The prototype web key distribution system demonstrates that functionality 
of changing Recognition Keys that will occur on a regular basis throughout the twenty- 
four hour window. The SQL Server generated the Recognition Key Table. A Web server 
served the appropriate global Recognition key down to each client browser. Four web 
browsers were opened on one computer screen and a PC other than the SQL server. Each 
browser was tracked by the web server and served the Recognition key. 

Each Recognition Key has a predetermined life of two (2) minutes each. 
Each Recognition Key is comprised of unique Hexadecimal (32 Digits) representation. 

32 Digits = 32 Nibbles = 16 Bytes = 128 Bits 


Number of hours /day 

24 ~ 

Number of minutes/hour 

60 

Shelf-life per Recognition Key 

2 minutes 

Total number of keys required per 24 hour 
period: 

720 Recognition Keys 


Table 2. Design Considerations For the Recognition Key Table 


Each key is selected dependent upon the time of the day. The algorithm 

used for determining the correct key to use for the generation of the Message 

Authentication Code (MAC) is: 

/Current Time - Starting Time) 

Lifetime of key 


A practical example of the key selection is as follows: 
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Total Number of keys 

720 

Starting Time 


Current Time 



Figure 26. Data for Example of Key Selection 


0800 - 0730 = 30 minutes = 15 
2 minutes 2 minutes 


Therefore, the Recognition Key index number 15 out of 720 is to be used in the 
construction of the MAC. The first fifteen keys are represented in the following 
demonstration table of Recognition Keys. 


Key# 

Recognition Key Index 

Recognition Key 

1 

AB71 

AB710BCF21218794321032321345F32D 

2 

ABE9 

ABE984038FCD63981CBD78F898A6D0 

3 

4038 

4038FCD63981CBD78CD63981CBABE0 

4 

9840 

984038FCD7 8CD63981CBD78CD63981A 

5 

D639 

D63981038FCD68CD63988CD6384038F 

6 

BCE2 

BCE271FA73923BC930AF44BC384038F 

7 

3840 

38403CDE5216AC73BCF8298BCF7208F 

8 

9040 

9040BCDF3840BC84B A28DC82 AC2D3 8F 

9 

674B 

674BC4DF789AC345DCB64BC21DS038F 

10 

3840 

3840BC4590982ADF423BCD32A231138F 

11 

BC45 

BC4537CADD2FF1908403C 384038F3840 

12 

ABC8 

ABC82821090ACBD7898A11FFS0901199 

13 

D9C7 

D9C769828DD579001AA63819AA84B189 

14 


6AA389ABCF43912CDFE80901AF34D117 

15 


BC80902734FF268732DAAEB22289871CA 


Table 3. Recognition Key Table 


The SAAM security manager module will use the calculated key index 
value of 15 to quickly identify the appropriate key to use with the generation of the MAC. 
The key and the outbound message are then passed via the MD5 algorithm to produce an 
MAC. The corresponding receiving SAAM Security Manager would quickly look at the 
time of the inbound message traffic to determine the appropriate key to use from its own 
copy of the SAAM recognition key table. Once the key selection has been completed at 
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the receiving-end SAAM security manager, a quick security validation process is 
conducted to determine if the inbound message is valid or to be discarded. The incoming 
message includes the key index that was used in the construct of the outbound message 
traffic, if the 4 digit key index attached to the message does not match the calculated key 
index derived by the in-bound security manager or the previous key index or the next key 
in the table then the message is discarded. If the message key index is valid then the 
message is extracted and run via the MD5 algorithm along with the calculated key. If the 
derived MAC matches exactly to the MAC of the inbound message server then the 
message is routed correctly via the SAAM OS. 

3. Full Protocol Prototypes 

A full prototype of the security protocol was developed rapidly in Visual Basic 
(VB). However, integration with the run-time SAAM Java prototype was not completed. 
Writing the Security Manager in VB was very fast for the author, compared to the 
difficulties encountered with Java and C above. 
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Figure 27. Security Manager User Interface in VB 


A major assumption is made for this prototype. It is assumed that SAAM 
is the user, literally pushing command buttons and filling in answers to questions when 
prompted. 
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Security Manager Prototype Flow 



Figure 28. VB Forms Diagram 

The flow diagram above shows how the VB forms relate to each other. 
The Main form is the first GUI that SAAM encounters. The initial state variables are 
assigned to the Security Manager based on inputs from SAAM. Three questions must be 
answered. (1) Who am I? (2) What is my current Security State? (3) Of the three 
scenarios for this security prototype, which scenario is currently running? These three 
answers must be stored. There is a tray, which holds these three state variables, 
displayed in the form of a background form in the upper right hand comer of the screen. 

SAAM then tells the security manager to do one of two things next. Either 
send a message, or receive a message. The Security Manager then processes the 
remaining steps, automating as much as possible with minimal participation from SAAM. 
Most of these other forms are information of what decisions the Security Manager has 
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made, and what is going to happen next. Finally a result is returned to SAAM, to be read 
into the Packet factory for further processing. 

This VB prototype demonstrates many of the intricacies that the Security 
Manager has to face, including what decision to make, what variables to store, variable 
scope, etc. Once the VB code is written, translating this code into Java is truly a trivial 
problem. There may be tools that automate the process of translating VB into Java. 

b. Lock Box Model 

Brian Tung’s Kerberos Box model was so successful that we decided to 
implement the entire protocol using lock boxes. This was the old fashioned way to 
demonstrate a new protocol, with people standing around a table, using boxes and paper 
messages to trace out the protocol. No computers were used, but concepts were solidified 
through these exercises. 
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VII. FUTURE WORK 


Concerning the JCSI prototype, the following work remains to be done. 

1. Tighter Integration with Packet Factory. 

The Packet factory is highly threaded. The exact location of where to add calls to 
the Security Manager still needs to be done. Prof. Xie gave suggestions about where to 
make calls within the Packet Factory. A detailed understanding of the code inside the 
packet factory is needed. More time is needed to add improved logic between Packet 
Factory and Security Manager. 

The behavior of the Security Manager is already developed in VB. Translating 
this VB code directly into Java would help. Each VB form can become a Java Class file. 
VB is taught in the ITM curriculum. A person with a background in VB could translate 
the VB Security Manager into Java, as an exercise to learn Java. Translating the Security 
Manager into Java could be a Java project in one of the Java classes taught at NPS. 

2. Implement in/out of Band Model. 

Our implementation was entirely out of band of SAAM for several reasons. The 
first was that JSCI was tightly integrated with IPv4. The second reason was that there 
was no flow id assigned for security protocol messages, and the current SAAM prototype 
only routes by flow. Further work on what parts of security are in-band should be done. 
For example, should the KeyTableResponse message be an in band message? 

3. Recognition Key Table. 

With more time, a full recognition key table can be created and sent over the 
Client Server session. Two efforts were ongoing in parallel to make this happen. One 
was the SQL generated key table, and the other effort was a native Java key table. Both 
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efforts completed a key table of 720 keys that were 128 bits in length, but the key table 
was never fully integrated into the protocol. 

The following general ideas remain as future work. 

1. REDLR is an acronym, which stands for Reconfigurable Intrusion Detection 
System. RDDLR is an ongoing project with the Information Warfare students working 
with LT Buettner, military IW instructor. RIDLR should be made into a resident agent on 
SAAM, for proof of concept. A future thesis student could be in the world of SAAM and 
the IW lab. 

2. Security has been incorporated into NTP. A review of the articles on Dave 
Mills’ web site, http://www.eecis.udel.edu/~mills/reports.htm, would help to evaluate the 
secure time synchronization we use in this protocol. The native NTP security could also 
be incorporated into the SAAM security protocol. 

3. How much time is saved by the quick reject behavior? The quick reject 
behavior occurs when the receiver of a signed message quickly evaluates the key index to 
see if this is an expected key index. If not, then the entire message is rejected before the 
hash is done. Once this is fully built into a prototype, sample data can be collected to see 
how much time is saved. The real question to ask is how many CPU cycles are saved by 
quick reject? It might be more difficult but not impossible to measure the CPU cycles 
saved. 

4. Kerberos is not the only possible answer for establishing a trust. IPsec could 
be used instead of Kerberos. 
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APPENDIX A. ORGANIZATIONAL BEHAVIOR EFFECTS OF 


SAAM 


A. CHAPTER SUMMARY 

This chapter is a case study on the effects that SAAM can have on organizational 
behavior. A Navy command is analyzed before SAAM is applied. The same 
organization is analyzed again after SAAM is applied. Two environmental factors that 
influence this study are the Military Technical Revolution (MTR) and the 1996 
Telecommunications Act. While many papers have been written from the strategic vision 
level for the entire Navy organization, this case study is unique because it addresses a 
small tactical level organization. The key learning points listed at the end of this chapter 
summarize the important aspects of this case study. Any active network would probably 
produce the same results. SAAM is used here as an example of an active network. 

B. STATEMENT OF PURPOSE 

The purpose of this case study is to determine the organizational changes that are 
likely to take place due to SAAM. The following case study describes a fictional Navy 
command, called the Center, which uses computer-networking technology that is 
common for the year 2000. An expert system called OrgCon is used to help analyze the 
organization in both the before and after scenarios. The benefits and limitations of the IP 
architecture will be explored. A new network protocol will be integrated into this 
organization, to allow quality of service (QoS) guarantees over the network. The 
resulting network and organization changes will be defined. 
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c. 


CHAPTER DEFINITIONS 


The term equivocality is used often in this chapter. High equivocality in the 
environment means that you don’t know what you don’t know. In the case of cyber 
warfare, capturing the techniques of a hacker can be a situation of very high equivocality. 
This is like finding a needle in a haystack. Technology changes so rapidly that the term 
“web time” is used to describe the compression of pre-Internet business with current 
electronic commerce. This time compression ratio is about 7:1. For every 7 years of old 
style business production, e-commerce business produces the same amount in 1 year. 
Defending against a hacker is like finding a needle in a haystack, and the haystack is 
constantly being shuffled. 

D. CASE STUDY ASSUMPTIONS 

The following assumptions have been made to frame this case study. 

The lack of promotion opportunities, command opportunities, and competitive 
pay are some of the disincentives that the Navy has as an organization. The rewards 
system for Information Technology (IT) careers in the Navy is no longer dysfunctional in 
this case study. [Kerr] In this case study, assume that the best and the brightest IT people 
are rewarded, producing incentives to seek to enter and stay in the Navy. 

The question of specialist versus generalist has been solved before this case study 
begins. The fine balance has been reached between daily Naval operations, and the 
infusion of relevant IT into every part of the Navy organization. IT has become like 
reading, writing, and arithmetic. Everyone in the Center is IT literate. That is not to say 





that everyone is a superstar, but everyone is familiar enough with network technology that 
they can quickly learn new technology that is related. 

In this study, the number of personnel is held constant through before and after 
analyses. Navy commands like the Center in this study can realistically expect an 
increase in the number of personnel because the Navy is just beginning to implement an 
Information Operations (10) strategy, guided by the vision of network centric warfare. 
[JV2010] No build up will take place in this study, in attempt to focus in on the 
organizational changes that occur due to SAAM. 

All major Internet Service Providers (ISP’s) support SAAM worldwide. SAAM is 
enabled just as any routing protocol is enabled in routers today. Assume that SAAM has 
been bought out by a large company that manufactures routers, and SAAM is now 
available as a feature throughout the Internet. 

Assume that SAAM is already a secure system for this case study. 

E. THE CENTER BEFORE SAAM 

The Center invested in a Local Area Network (LAN) upgrade only two years ago. 
LAN bandwidth locally was increased from 10Mbps to 100Mbps, a full order of 
magnitude change. However, the latest applications were already stressing the throughput 
on this network, due in part to the party line nature of Ethernet. As more and more 
people join in on the party, there is more talking at once, known as collisions. 

In the Center, the increase in network collisions was not due solely to an increase 
in number of computers on the LAN. In this case, the newest applications are demanding 
more from the network. Multicast streaming video, video conference calls, remote 
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network monitoring agents, and voice over IP are just some of the applications that have 
bogged down the LAN in recent months. The topology of the LAN Before any changes 
are made is shown below. 



Meet Luke Ellington. He’s the manager of this department, which is at the heart 
of the business operations. That is why this department is called The Center. As a Navy 
command, all the workers in The Center are well acclimated to the traditional machine 
bureaucracy organization found everywhere in the military. The entire department 
consists of only ten people, organized into two divisions. Bob is the division officer of 
the computer operators. All people in this division are active duty, bringing with them a 
range of current skills in the computer networking industry. Alice’s division is a mix 
between active duty, civilian, and contractors. Contractors are hired for projects where 
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existing expertise is lacking. Contractors also train others during development and 
installation of a new system. The organization chart of The Center is as follows. 


Before 



Figure 30. Org Chart of The Center - Before Scenario 
The main business process of The Center is to provide network security support to 
Naval commands, including almost every command in the Navy. The number of 
computer user seats in the Navy is in the range of 400,000. The potential for security 
breaches in this large enterprise is the motivation for standing up The Center, which is 
only five years old. 

Most Navy commands have a deep history and experience to pull from in times of 
crisis. Information technology has been dominated by the private sector for less than two 
decades, a short time compared to the US Navy’s 200+ year history. Tradition runs 
strong in the Navy, but this giant organization saw the need for a forward thinking 
networking command to help deter the threat from the enemy over Internet. This new 
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form of national defense is called information operations (10), which is a more strategic 
view of all things in the information warfare (IW) arena. And so The Center was bom, by 
order of the Chief of Naval Operations (CNO). Though young in years, The Center has 
never ceased to be in the limelight. 

There is an organizational tendency for LAN administrators to become “Data 
Czar’s,” hoarding massive organizational control. At times, the LAN administrator has 
control over files that used to be readily accessible in a physical file locker. If the LAN 
administrator is holding too many keys, then the organization suffers when individuals 
cannot get their data because the LAN administrator is busy fighting fires elsewhere. 
Over-ambitious LAN administrators exhibit this behavior when the organization rewards 
it. This breeds a lack of trust and rice-bowl mentality, where knowledge really is power. 
The center is a collection of well-seasoned IT professionals, chosen in part for their 
personal grace under pressure and teamwork. The center has been able to avoid this Data 
Czar mentality, through professionlization. Professionalization means that employees 
have completed a rigorous standard education of many years, such as medical doctors. 
People at the center have seen this before, share a common business history in a sense. 

1. Environmental Factors 

The Center is a unique command in the Navy. The very existence of the Center is 
due to the Military Technical Revolution (MTR). While most admirals today have no 
direct experience at using the Internet as weapon, most do realize the importance of a 
solid Information Operations (10) infrastructure in the Navy. The fact is that the civilian 
population in the USA was exposed to direct attack from any cyber-terrorist, and the 
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military was not capable of defending our population at all. The figure below 
demonstrates this idea. 



Figure 31. Military Without 10 

The strategic view is to maintain Information Superiority, forcing the aggressor to 


go through the military before attacking the population. 




Figure 32. Military With 10 

The Center is one of the commands created to make this strategic view a tactical 
reality. That is why the Center has an increasing budget. When most commands have 
ever shrinking budgets, the Center is actually expanding. Still, the budget at the Center 
undergoes careful scrutiny to ensure that spending is done wisely. This budget increase is 
nothing compared to the order of magnitude difference seen during the military build-up 
during the 1980’s. 

The spotlight is another environmental factor. Commands like the Center are in 
the spotlight from above, gamering high visibility from the highest-ranking officers in the 
Navy. The theory of social facilitation applies to center, even from an organizational 
level rather than individual. When performing a well-known task and the Center is aware 
that it is being watched, the task is done extremely well. When performing a task that is 
not well know and the Center is aware that it is being watched, the task is not done as 
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well as it would be without an audience. Learning new technologies on an operational 
network is difficult to do. 

The final environmental factor of great influence to SAAM is the 1996 
Telecommunications act. This legislation basically makes it legal for the telephone, cable 
and Internet companies to compete in any of these three industries. [Lewis] Thus, free 
competition legally exists between voice, video, and data. The legislation applies most 
directly to private companies. Since the military now uses commercial solutions, COTS, 
the Telecom Act affects the Center. Specifically, the Center is currently paying bills for 
telephone access, dedicated data lines at T-l speeds, and a separate bill to connect to the 
Internet. It would be ideal for any customer of telecommunications services to combine 
all these services to pay a much smaller bill. 

2. Analysis of Before Scenario 

The following is taken from the results OrgCon, the expert system. 

The quality of people working at The Center is very high. Postgraduate education 
levels are greater than 60%, including all the enlisted personnel. It is common to see 
senior chiefs (E-8) with master’s degrees in technical and managerial fields. The level of 
trust within The Center is very high. The group is small and highly educated, giving an 
influence towards a professional organization. Small mistakes are tolerated, so long as 
the mission is not impacted. But as any Navy command, there is not much room for 
failure. Luke’s leadership style is basically risk avoidance. Still, this is not quite as 
extreme as the zero defect mentality that pervades other Navy communities. 
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The environment in which the Center operates is to face the constant security 
threat from the global Internet. State sponsored hackers and phreakers are constantly 
innovating new ways to snoop on Navy commands. The Center must be agile enough to 
out step this threat, and vigilant enough to manage any attacks that could not be 
prevented. There are not many written Standard Operating Procedures (SOP’s), although 
the few pass down items of mundane computer operations are written and followed. The 
people in The Center are given enough room to develop new and innovative solutions to 
cutting edge technology problems. 

The developmental climate is characterized as a dynamic, entrepreneurial and 
creative place to work. The tendency for people to stick their necks out and take risks is 
held in check by a risk averse Navy culture. The glue that holds organizations together is 
commitment to experimentation and innovation. The emphasis is on being on the leading 
edge. Readiness for change and meeting new challenges are important. The Center's 
long-term emphasis is on growth and acquiring new resources. Success means having 
unique and new products or services and being a product or service leader is important. 
The Center encourages individual initiative and freedom. 

The Center has a high level of trust and a group climate. High morale is one 
element of group climate. Highly equitable rewards within The Center drives the climate 
towards a group climate. The Center has a low level of scapegoating, which is also 
conducive to the group climate. 

Since Luke and his boss are constantly under the scrutiny of Washington DC, he 
has a preference for being very involved in gathering and using detailed information when 
making decisions. A high preference for micro involvement characterization is 
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appropriate. Management is risk averse, which is one of the characteristics of a manager 
with a high preference for micro involvement. Because The Center is a small 
organization the preference for micro involvement will be higher than it would otherwise 
be. 

The Center’s strategy can be characterized as an analyzer without innovation 
strategy, which is an organization whose goal is to move into new services only after their 
viability has been shown, yet maintains an emphasis on its ongoing services. It has 
limited innovation related to the production process; generally an analyzer without 
innovation does not have product innovation. Most new services that The Center 
provides come from an external order from a higher authority, rather than from demand 
from the customers or from innovation in house. 

The capital requirement of a hacker is not high. However, the capital requirement 
for the Center is high because it must purchase enterprise level security systems, such as 
complex intrusion detection system. This high capital requirement is consistent with an 
analyzer without innovation strategy. Any hacker who wishes to infiltrate the US Navy 
can do so with a home PC and a connection to the Internet. This is now in the price range 
of below $500. With a very routine technology, new products for new customers are not 
very likely, although the firm can copy a few products. Therefore, strategy is likely to be 
analyzer without innovation. With a concern for high quality an analyzer without 
innovation strategy is a likely strategy for The Center. 

The Center has both a routine technology and a highly equivocal environment. A 
more non-routine technology is a better fit with an equivocal environment. A routine 
technology produces services efficiently which are standard and without variation. In a 


89 




highly equivocal environment such as combating hackers on the Internet, it is likely that 
the Navy commands who are customers will demand variation in the product and service 
characteristics. Hackers are likely to introduce new products, modify footprints, etc. 
Further, in the equivocal environment, large changes can come from unforeseen actions 
by hackers, foreign governments, and breakthrough innovations from our own Silicon 
Valley available to the world at large. A more non-routine technology will be required to 
adapt to the unknowns and changes of an equivocal environment. 

The Center has both a routine technology and a high requirement for product 
innovation. This situation must be changed; a routine technology will not support high 
product innovation. A routine technology yields standard services with low variation. 
The need for service innovation creates a mismatch. Service innovation will be difficult 
to manage, expensive and inefficient. For service innovation, a more non-routine and 
adaptable technology is required. Of course, the Center does not have the option of 
changing to a different environment where less innovation is required and a routine 
technology is suitable. 

The Center has a developmental climate. This is a mismatch with the leadership 
being risk averse. Leadership in this sense includes Luke and his entire chain of 
command. A development climate is relatively flexible and externally oriented, 
characterized by low conflict, low resistance to change, and high leader credibility, 
among others. Risk averse leaders generally avoid uncertainty and generally also 
minimize change. The risk averse leader will not be comfortable in a developmental 
climate and may introduce more control to reduce the uncertainty. 
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The Center tends to move toward a developmental climate. This is a mismatch 
with a highly routine technology. A developmental climate is flexible and has an external 
orientation. It has low resistance to change, low conflict and high leader credibility, 
among others. A routine technology is more compatible with a climate of stability and 
there is not much change. The focus is on running the routine technology. A 
developmental climate can support a more non-routine technology where adaptation and 
variation are the norm. 

Since the set of variables in the environment that will be important is not known 
and since it is not possible to predict what will happen, no efficient rules and procedures 
can be developed, which implies that the Center’s formalization should be low. A 
developmental climate in the organization requires a low level of formalization. 

When the environment of the Center has high equivocality, high uncertainty, and 
high complexity, coordination and control should be obtained through integrators and 
group meetings. The richness of the technical media should be high with a large amount 
of information. For example, large screens and visualization should be present in the 
meeting room where executive decisions are made. Incentives must be results based. 
When the organization has a developmental climate, coordination should be obtained 
using planning, integrators and meetings. Incentives could be results based with an 
individual orientation. An organization with a developmental climate will likely have to 
process a large amount of information and will need information media with high 
richness. 

Top management, Luke, should make many decisions. However, many 
individuals should be involved in gathering information and implementing those 
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decisions. Top management should gather information, make decisions, and manage 
implementation. Top management should give direct orders to achieve the required 
coordination among the operations and activities. 

The following organization misfits are present in the Center before SAAM is 
applied: 

Current and prescribed configurations do not match. 

Current and prescribed complexities do not match. 

F. MOTIVATION FOR QUALITY OF SERVICE OVER IP 

Sidgmore’s Law - the number of packets on the Internet backbone doubles every three 
months. This means that the number of packets on the Internet backbone increases by 
about 16 times per year. [Lewis] 

Most of the intrusion detection systems run over the shared line, which goes out 
into the Internet. The LAN diagram above shows this shared line connecting the router to 
the Internet. Some critical applications currently run over leased lines. The leased lines 
go out to the local telephone company at a recurring cost of $1000/month. [Redshift] The 
Center has four leased lines, one of them being the T-l connection out to the Internet. 
The recurring cost of the other three lines has come into question by Luke’s superiors. 
He has financial pressure to relinquish one or two of those leased lines. 

At the same time, Luke’s technical workers tell him about application failures due 
to network congestion. Applications that monitor other networks need to have a clean 
connection to the customer sites, and that connection must be in band with all the other BP 
traffic to be effective. The monitoring software must flow along with the regular traffic. 
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In order to find the bad fish, you must set your decoys to swim with the whole school. 
Routers are dropping LAN packets during times of heavy congestion. 

Luke is offered several options: 

• Eliminate two leased lines and forget about technical requirements for more 
bandwidth. 

• Buy more leased lines and forget about senior input. 

• Witch-hunt. Find the offending applications on the LAN and eliminate all 
applications that are not specifically defined as mission critical. Luke has recently 
heard that the streaming video his crew has constructed on how to configure a 
firewall has won praise from the Navy commands the Center services, and this is 
reflected in comments from Admirals above him. Yet Luke also knows that this 
is one of the applications that is eating away at his precious bandwidth. 

• Institute a Quality of Service system over IP. 

Luke chooses plan d, which is the best balance of budget pressure from above with 
bandwidth demands from below. Choosing a QoS over IP solution makes sense for the 
center. From the financial perspective, the Center will eliminate the recurring monthly 
cost of $3000 per month. There will be a one-time cost to install the QoS system, but it 
will take about six months before the breakeven point is crossed and the new SAAM 
system pays for itself in cost savings. 

Technically speaking, the level of service on the old dedicated lines is very high. 
The videoconference node on one end receives real time traffic from the other end. There 
are few blips and static. Once in a while, the connection is dropped for one reason or 
another. When that happens, the screen freezes. But the sound and video are pretty clear. 
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This is contrasted with the Voice over IP (VoIP) system, which has a noticeable decrease 
in service level. There are occasional blips of silence mid conversation. Sometimes, 
during mid day when everybody is busy at work, the VoIP system is almost unusable 
because of congestion. So the question that Luke must answer is how to migrate his 
video conferencing application to the IP world, while still maintaining the high quality of 
service perceived by the end users. 

The current Internet uses one service level model for all IP packets. Best effort 
service means that all packets on the Internet have equal priority. When there is an 
overload of packets, the packets are dropped. The suggestion to use Asynchronous 
Transfer Mode (ATM) was rejected based on price and the lack of ability to ‘take care of 
the last mile’ and offer ATM QoS all the way into the home. Luke often finds himself 
doing work on nights and weekends from home, sometimes speaking with a force 
commander in a time zone 12 hours away. There are four QoS over IP models that Luke 
has available to him: (1) Integrated Service, (2) Differentiated Service, (3) Multi Protocol 
Layer Switching (MPLS), and (4) Server and Agent based Active Management (SAAM). 

G. THE DECISION TO USE SAAM 

Integrated Service offers a guaranteed class of service. The problem is that many 
telecom carriers do not offer Integrated Service because there is no way to meter and 
appropriately charge who is using the bandwidth. On the other hand, differential service 
looks promising at first glance. Luke will be able to set up his applications to be either 
premium service, assured service, or best effort service and pay an appropriate price tag 
for each. MPLS does much the same thing, with per-class guarantees and routers that 
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dynamically change their own state. The price quote below is an example of how the 
local Internet Service Provider (ISP) and/or telephone company could price the different 
service levels in differentiated service. 


SERVICE 

PREMIUM SERVICE 

ASSURED SERVICE 

BEST EFFORT SERVICE 

BANDWIDTH 

REQUIREMENT 

128 KBPS 

FRACTIONAL T1 

384 KBPS 

FRACTIONAL OF T1 

768 KBPS 

FRACTIONAL T1 

(REMAINING 

BANDWIDTH) 

ISP CHARGE 

$3599.95 MONTHLY 

$1495.95 SETUP 

$1999.95 MONTHLY 

$1495.95 SETUP 

$659.95 MONTHLY 

$1495.95 SETUP 


Table 4. Pricing Model for Differentiated Service 


At first glance, this looks promising to Luke. However, the problem is that 
differential service only makes per class guarantees, not per connection guarantees. 
When he runs the video teleconference (VTC), he does not want that to lose out to other 
high priority traffic, such as the remote intrusion detection systems. The other technical 
problem is that when all of the premium service bandwidth is in use, the network begins 
to drop premium packets and quality is deteriorated. 

Luke looks to SAAM for a solution, and finds that he can have per connection 
guarantees. Each application can enjoy high QoS as needed, with higher priority 
applications always gaining the bandwidth they need. This means that he can have his 
network monitoring software running in the background, while holding a video 
teleconference at the same time. If somebody begins to place a VoIP phone call, they will 
get the remaining bandwidth available, and the phone call will not impact the video 
teleconference at all. SAAM guarantees an end-to-end connection for each application. 
The pricing model for SAAM is shown below. 
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APPLICATION 

VTC 

VOIP 

NETMON SOFTWARE 

BANDWIDTH 

128 KBPS 

384 KBPS 

768 KBPS 

REQUIREMENT 



(REMAINING 

BANDWIDTH) 

ISP CHARGE 

$2599.95 MONTHLY 

$999.95 MONTHLY 

$659.95 MONTHLY 


$1495.95 SETUP 

$1495.95 SETUP 

$1495.95 SETUP 


Table 5. Pricing Model for SAAM 


The price to institute SAAM is lower than any other option and each specific 
application can be guaranteed the required level of service. Because SAAM runs over IP, 
there is no wasted bandwidth. As each application ‘hangs up’ the bandwidth is re¬ 
allocated and not wasted. Recall that all major phone companies and ISP’s support 
SAAM today. Luke will be able to run video teleconference (VTC) software and get a 
good connection all the way to his home PC now. 


The figure below summarizes a comparison of the QoS over IP options available. 



WIDELY 

SUPPORTED 

PER-CLASS 

GUARANTEES 

PER-FLOW 

GUARANTEES 

ROUTER 

OVERHEAD 

LOCATION 

FAIR PRICE FOR 
BOTH TELCO 
AND CONSUMER 

INTEGRATED 

SERVICE 

NO 

YES 

NO 

INSIDE 

NETWORK 

NO 

DIFFERENTIATED 

SERVICE 

YES 

YES 

NO 

INSIDE 

NETWORK 

YES 

MPLS 

YES 

YES 

NO 

INSIDE 

NETWORK 

YES 

SAAM 

YES 

NO 

YES 

OFF 

NETWORK 

INSIDE 

SERVER 

YES 


Table 6. Summary of QoS Options 


Luke decides to implement SAAM in his network. 


H. MIGRATING TO SAAM 


Managing the issues involved in the specific migration should begin with the following 
generic checklist. This checklist is only a starting point and should be tailored to meet the 
needs of the specific organization. 
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Checklist for Migrating to SAAM 

Identify applications that require service level agreements (SLA’s). Some of these 
applications might include voice over IP, fax over IP, video conferencing, 
streaming audio and video, virtual private networks, hosted applications, e-mail, 
messaging applications, content, ftp with verified sent, and network games. 
[Xacct] 

Assign importance to those applications. 

Training. This can run in parallel with other tasks. 

Shop for best value on SAAM. Which ISP offers the best product for this 
organization at the lowest cost? Set up formal service level agreements with the 
ISP or local telephone company. 

Conduct a cost benefit analysis to determine the break-even point. 

Implementation. 

• Perform upgrade in house or outsource? A good professional IT staff will 
be capable of the upgrade in house. The Center would upgrade in house. 

• Test roll out in a test lab first. Red teams the test lab. Try to imagine what 
the very worst nightmare of an enemy. The red team should make us 
sweat and work hard. 

• After action review. 

• Roll out SAAM for real. Start with non-operational subnets, such as the 
administrative LAN. Next, enable SAAM on the operations subnet, the 
backbone, the choke router and finally out to the first hop on the Internet. 



• Analyze progress. Keep the feedback loop running throughout the 
implementation. 

• Allow time for SAAM to stabilize. There will be some growing pains in 
the organization as people become used to SAAM, especially the first few 
hours, as the routers in the Internet adjust. 

I. THE CENTER AFTER SAAM 

The ability to guarantee QoS affects the local network in the Center. The 
applications that need bandwidth now get it when and where they need it. The Streaming 
video server begins to be used far more than before, as more and more Navy personnel 
discover this service available to them. Training on firewall setup is crucial throughout 
the Navy enterprise. This streaming video server has been changed to a beefed up 
platform to service all the hits. The video teleconferencing is going well. With no 
degradation in service, Luke has managed to migrate the video teleconference 
applications and save that recurring cost of the dedicated lines. The Voice over IP service 
has been rolled out throughout the center now that the quality is about the same as a 
regular phone call. In the past year, only about two VoIP phone calls have been dropped, 
which is comparable to the statistics of using the old phone company lines. Once again, 
the cost savings is enormous. Even though the Center had autovon available to them, the 
quality was so poor for phone calls to long distance sites throughout the world. The new 
VoIP solution was saving the Center some $2000 a day, every 24-hour period. Also, the 
main service provided by the center no longer blinked out during times of high Internet 
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congestion. The monitoring agents maintained an awake state straight through the year, 
with 99.999% uptime. 

Perhaps the most notable change in the network is the creation of a practice lab. 
This reproduces the operational network. The practice lab is for development and 
integration of new tools. For example, SAAM was first integrated on the practice lab. 
The practice lab is expected to fail occasionally, so no operational systems rely on it. In 
fact, the practice lab is essentially an isolated network, allowing for traffic to the Internet. 
The practice lab was also deemed necessary because of the high equivocality in the 
environment. As new 10 attacks are discovered, the details of defending against them are 
uncovered in the practice lab. The figure below shows changes made in red. 



In addition to the technical changes that have taken place, the organization has 
now changed. The overall configuration has moved to a simple configuration. All people 
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in the Center now report directly to Luke. This flattens out the organization, allowing for 
fast reaction to new problems that arise in the environment. This increases the direct span 
of control for Luke, but it is only ten people, which is still a very small organization. 
Also, the people in the center are highly trained professionals in this particular field. 
Strict rules and regulations can hinder their progress more than help, because the working 
core best understands the solutions to problems. 

Two billets that are interesting to note are the IP Engineer billet and the Telecom 
billet now overlap so much that they could be considered one job. This is demonstrated 
in the Org Chart below, showing Pedro right next to Joanne. Both billets now run the 
combined Telecom and IP system. This is a potential source of friction because an 
organizational boundary has been removed by SAAM. However, no jobs need to be 
eliminated. Filling the Telecom/IP Engineer billet will need redundant personnel, 
because Telecom and IP have become such a critical function to the Center. 
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Figure 34. Org Chart of the Center from External Point of View 
This organizational chart is still used when reporting to senior officers or 
commands. However, the internal organization in the Center has really moved more 
toward a simple organization. The reason for this change is due primarily to the high 
equivocality in the environment. This Navy command has become like an Internet 
company, able to change direction to a new product, and able to move forward in that 
direction at a high velocity. The environment demanded such a rapid pace, and the 
bureaucratic structure did not easily accept rapid changes. 
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Figure 35. Day-to-Day Working Organization After SAAM 
After the advanced network is applied, the organization functions more like a 
team. Each person brings with them a technical specialty to support Luke, the decision 
maker. Problems are solved with ad hoc solutions, rather then pre-programmed answers. 
Agility is gained from this organization. Also, this organization is only as strong as its 
weakest link, so there are strong group norms to work hard and keep Luke on top of the 
latest and greatest technology. 

This is a cultural change from the external Navy environment, but different 
community cultures in the Navy do exist and thrive. For example, the culture within an 
air wing is almost a professional bureaucracy, with each highly trained pilot trusted to 
make the proper decisions while flying in combat. Without this dynamic culture, the 
Center could not survive. This disparity between the Information Warrior culture and the 
Navy Line culture will continue to be a source of friction. Hackers are not bound by 
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bureaucracy. On the other hand, hackers do not have the benefits of a large standing 
bureaucracy to draw resources, knowledge, and experience from. The Center is in a 
unique situation. 

J. ANALYSIS OF THE CENTER AFTER SAAM IS APPLIED 

The following is a discussion of results from OrgCon. 

The personnel working in the center are highly professionalized. This still has not 
changed, and all the related factors remain the same. The level of trust remains high and 
scapegoating remains low. 

The issue of risk taking has been addressed. The Navy enterprise is a risk 
avoidant culture, but the Center needs to experiment and innovate in order to sufficiently 
defend other Navy commands. This paradox was the thinking behind the practice 
laboratory. The practice laboratory offloads risk. Now the personnel can try new 
products and services for evaluation quickly, without incurring additional risk to 
operations. The practice laboratory can also be used for self-training on specific technical 
issues. The practice laboratory also facilitates the current operations routine technology 
of the center with the uncertain environment. This situation can cause problems for which 
a more non-routine technology is better. 

The old written SOP’s were essentially useless. Pass down information is more 
reliable because of the short time in which a pass down can be written. The information 
is still current. This is in contrast to the out of date information in SOP’s, which took a 
longer time to develop. The external Navy environment will want to see SOP’s, 
enforcing this expectation with IG inspections. The Center now has a large manual that is 
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maintained and kept up to date. It is called the SOP manual, but it is not a traditional 
Navy SOP. Rather, it is a modular collection of pass down items, updated almost daily. 
As shown in the org chart, a new duty on documentation is created and managed by one 
person. Bob compiles everything into the SOP book, but he uses everybody else’s 
knowledge to do this. Other people often submit written pass downs to him. This SOP 
process is very informal compared with that of the larger Navy. 

The simple structure accommodates the micro involvement that Luke must have 
with this people. When a customer is hacked, Luke must understand the details of all that 
took place so that he can properly speak with higher ups about the incident. The old 
hierarchy of middle management was an impediment to the business process of reporting 
incidents accurately and concisely up the chain of command. 

Top management, Luke, still makes many decisions. The relevant input from 
personnel is still taken but ultimately the boss of the simple organization makes the final 
decisions. 

After SAAM is applied, there are no organizational misfits. 

As a technology, SAAM is no longer divisible from the organization. It is part of 
the entire network. Even though there may have been a SAAM specialist during the 
installation phase, SAAM is now pertinent to all network personnel. SAAM affects 
everybody. 

The network with SAAM is now an adequate tool for the job at hand. Within the 
Center, applications that require real time delivery now function properly, all the time. 
The product that the Center delivers to the outside customers is a service. Now that 
SAAM is used on the entire path from the LAN inside the center, through the Internet, the 
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service that the Center provides is more real time. The Center now advertises that it 
delivers real time security service, with information continuance. Information 
continuance is the business term applied to the overall effect of active networks with 
QoS. [Aberdeen] Just as sure as the Internet will survive a nuclear blast on any node, the 
information coming from the Center will continue. 

Technically, implementing information continuance is done when a network 
application is configured with service level agreements. High priority is given to specific 
flows within intrusion detection applications, remote monitoring applications, streaming 
video apps, voice over EP, and the teleconferencing app. 

K. RATIONAL SYSTEMS MODEL 

The rational systems model was used to analyze the organizational effects of 
SAAM, in attempt to view the Center as a system, with inputs, some business processing 
within, and some outputs. 

In the Environment of the Center is the larger Navy, and specifically the CNO’s 
office who has a large stake at seeing the Center succeed. The Internet Service Providers 
(ISP’s) have a steak in the center once SAAM is enabled because these two organizations 
must have Service Level Agreements that cross-organizational boundaries. More than a 
contract, this can be viewed as almost a partnership for high quality telecom service. The 
customers are the Naval commands with networks, who use the special security services 
of the Center, and they obviously have a stake in the success of the Center. 

There are opportunities in the environment. In order to remain a first rate Navy, 
the Center must provide an active network with QoS over IP capability, which SAAM 
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does. There will be a short term cost savings to show, but ultimately the Center must 
have an up to date network or cease to exist because the industry will over run it. 

The threats in the environment include the hackers, both foreign and domestic. 
The Center has a short history of only five years. This provides opportunity to make a 
dramatic cultural change toward IT teamwork of professionals in uniform. This culture in 
IT fields is an ideal of the Navy but not actually supported by the current Navy, due to the 
dysfunctional rewards system and other factors. There is hostility in the environment. 
The rapid change of technology is a constant threat of making the Center obsolete. 

Moving into the organization, the strategic view driving the Center is Network 
Centric Warfare (NCW). The objectives for today are to become a real time organization, 
able to run core Observe Orient Decide Act (OODA) loops in microseconds. The short¬ 
term path of attaining this strategy is to defend Naval networks. 

There are many critical success factors to the successful adoption of SAAM and 
subsequent organizational improvement. There must be executive support for SAAM. 
Luke must drive it forward. No other position has the proper authority to make it a 
success. Even if someone higher than Luke forced the Center into using a new 
technology, it will be less successful than having Luke drive it forward. SAAM must be 
readily available in the ISP, as stated in one of the main assumptions. In today’s terms, 
SAAM should be a feature bundled into Cisco IOS. The only viable business plan for 
SAAM right now is to get bought out by Cisco. No ISP would change all their routers to 
a small third part company just to gain SAAM. One note on the migration path must be 
made. SAAM will work with other QoS systems, such as RSVP and DiffServ, so as 
ISP’s adopt the best QoS system, interoperability will be there to take advantage of legacy 
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systems. Furthermore, it is assumed that SAAM is a secure system, not introducing new 
gaping security threats to an already insecure Internet. Another critical success factor is 
the professional personnel inputs into the Center, each person IT literate with a 
subspecialty. Also, each person must be a team worker. 

The following discussion of the internal works of the Center is organized into 
three different levels, the organization, groups, and people. 

The size category has a small tactical organization of 10 people. The groups are 
formed around problems. Teamwork is required in almost every solution. The people are 
highly educated in IT, able to think abstractly on what technology can do to solve 
concrete problems, bringing credentials from universities and industry training 
certifications. 

The tasks inside the organization vary from day to day, but the focused mission 
today for the organization is Computer Network Defense (CND). The groups are formed 
dynamically around problems. The subspecialty of each person is a unique contribution 
to the whole to support the leader, Luke, in making decisions. 

The core technology is CND. For groups, red teaming new systems and ideas is a 
core technology and how the Center operates. These red teams are stressful tests. The 
day-to-day operations between people is a workflow process. Individuals cannot really 
complete a business process from end to end. People in the Center need each other. 

The information and communications is really the industry in which the Center 
works. So this permeates the entire organization. Open communications are required 
between groups. Fast response is needed from each individual. E-mail and other network 
technologies are good examples of the speed of business on the Internet. 
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The structure of the Center has changed dramatically from a machine bureaucracy 
to an informal structure of informal roles or billets. Now the organization is able to 
evolve quickly around threats and opportunities. The new simple structure is like an 
adhocracy. The groups are again loose structures, dissolved after that project is complete. 
One permanent change due to SAAM is the merge between the telecom IP engineer roles. 
The structure relies on professionalized individuals in the IT field, which a broad 
knowledge domain or schema in IT. Only after one knows how to use a hammer will 
swinging it harder make forward progress. Hard work from such professionals will drive 
the organization forward. 

The rewards system within the Center is based on results. The goal of the rewards 
system is teamwork and a customer focus. One reward, which is particular to the IT field, 
is “just for me training.” The organization is willing to spend money on training classes 
or certifications as a reward to an individual IT career, even if that skill is not something 
that the Center needs immediately. Not only does this make people feel taken care of and 
motivate sharp people to continue working hard, but it provides more opportunity for the 
center to randomly find a new technology, a new opportunity for the organization. 
Individual rewards also help to make the goals of the individual in line with the 
organization. Standard Navy awards are given, representing intangible glory in the form 
of medals. Honor is a big driver for military people. This part of Navy culture should be 
maintained even though other cultural aspects are dramatically different. Command 
opportunity can be built at the center through a series of good written evaluations and 
fitness reports, specifically mentioning command in the future for this individual. The 
civil sector is able to reward its personnel with stock options. If that could legally be 
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worked into the Navy, this reward would further the Center as a rival in the private sector. 
The idea that ‘nobody gets rich in the Navy’ is a cultural barrier that would have to be 
overcome to offer stock options. 

The flow of these rewards must be noted. The Center cannot really provide 
command opportunity for people, since the Center already has a commander. But the 
written evaluations from the Center can go a long way toward an individual’s future 
command opportunities. The Navy boards actually do the prompting and command 
assignments. The Center can even leverage its high visibility and frequent contact with 
the CNO’s office, by asking for the CNO’s signature on the best awards and written 
appraisals. 

The training in the organization takes into account the professional nature of the 
individuals, with a 75% rate of higher education. Training focuses this strong mental 
capacity to imagine a solution. There are routine group training events, about once a 
week in the Center. Some specific training occurs when new systems are installed. 
Individuals are trained toward industry certification. This might even be part of the Naval 
boards of review in the Center. Continuing education is a part of maintaining the schema 
for IT. Individuals go out in town to take a university class regularly. 

The people influence in the Center is noted from the high visibility of the 
organization. Social facilitation theory applies to the organization, groups, and 
individuals. [Greenberg] The individuals in the Center have the potential for big impact 
on the Center, as well as the external Navy enterprise. Each person is a big fish in a big 
pond. 
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The symbolic/interactive cultural aspects of the organization are items such as 
operating in Internet time. If the Internet moves in dog years, with a 7:1 ration, then the 
Center has to move fast. Three laws drive this rapid pace. Moore’s Law, the tendency 
for the number of transistors on a CPU to double every 18 months, can be mapped to the 
tendency for the life cycle of a software system to live for only 18 months. Sidgemore’s 
law notes the 16-fold increase in bits on the Internet every year, driving the need for QoS. 
Davidow’s law is the need to obsolesce your own product before your competitor makes 
your product obsolete for you. [Lewis] The individuals in the Center understand all of 
these laws. This helps them remember that the Center is a fast twitch organization. 

The outputs from the Center with SAAM include end-to-end information 
assurance. Automated network monitoring is improved with the smart agents 
programmed in. The groups produce a high quality, high group morale, which extends 
out from the Center to customers working with the center. The team of IT people at the 
customer end of the Center have a very positive experience of working with the Center. 
High customer satisfaction is a product of the Center. High individual satisfaction is a 
product of the Center. The individual member in the Center must be challenged and 
satisfied to continue the rapid pace of work required, noting that the rewards system and 
individual training reinforce this. 

The overall outcome is that the Center provides unbeatable computer network 
defense service, rivaling even the private Internet companies if not beating them. The 
outstanding customer feedback arrives back to the Center immediately and reinforces 
good work. This feedback is also noted by the Naval superior commands, especially the 
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CNO. The final outcome is continued funding from the CNO. As the popular military 
saying goes, “If you just do this, you get to keep your job.” 
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Figure 36. Rational Systems Model - page 1 of 2 
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Figure 37. Rational Systems Model - page 2 of 2 
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L. KEY LEARNING POINTS 

Migrating from a legacy Local Area Network (LAN) to an active network has 
many organizational impacts. 

1. Time Compression 

The active network compresses the response time of intrusion detection systems, 
ultimately producing a faster service from the Center. On the Internet, faster is better. 
This time compression benefit facilitates risk-embracing leadership, which is needed to 
outpace the enemy. SAAM allows the Center, and Luke, to do near real time situation 
assessment and respond appropriately. SAAM makes the center into a fast twitch 
organization. 

2. Information Parsed into Knowledge 

Humans are still needed for problem solving. SAAM brings all the relevant data 
and reports to these decisions. For example, Luke could request reports of number of 
network probes that have found suspicious activity, analyzed in both space and time. 
These reports can be updated with real time data, using the QoS nature of SAAM. 

3. IP and Telecom Barrier Removed 

The barrier between the IP engineer billet and telecom billet has completely 
disappeared. This could become an organizational source of friction. Cooperation is 
easier to accomplish between individuals than would be if two separate divisions 
performed these two functions. 
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4. 


Teamwork 


The SAAM network connects teams rather than individuals together. 

5. Training Shipped to People 

Training is done over streaming video and video teleconferencing calls. The 
travel budget is reduced by several orders of magnitude. Also, Video Teleconference 
VTC can replace the site visits from the Center. Training is shipped to the people, not the 
other way around. 

6. Quality of Voice Over IP 

It is a common misconception that the quality of a voice conversation over a 
dedicated phone line cannot be matched by using a regular IP network. This idea does 
not stand true in this case study. Quality of service does apply very well to services on IP 
networks using SAAM. The quality of a switched network is matched with SAAM over 
IP. The old QoS protocols failed for several reasons. The main reason is the service 
model is used, causing moments of congestion in the stream of data, and audible silences 
and repeats. The flow based routing model in SAAM eliminates bottlenecks from end to 
end. Once a flow is established, there is no competition from lower priority flows. 

A related argument is that Voice over BP was already in place before SAAM came 
to be, suggesting that SAAM is not needed. In the late 1990’s, companies such as Cisco 
had already successfully deployed Voice over BP worldwide, without using SAAM. The 
confounding factor is that Cisco owned the entire WAN used for VoIP. Most 
organizations rely on the public Internet, including the Navy. SAAM works over 
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heterogeneous networks. Many ISP’s are in involved in a SAAM data flow from one 
SAAM endpoint to the other. 

7. Fewer Layers in the Organization 

The rigid command bureaucracy in the Naval culture is adjusted inside the Center 
to become more like an Internet company as found in Silicon Valley. As the network 
advances, the organization becomes more of a simple organization. Advanced networks 
tend to flatten out organizations. 

M. CASE STUDY CONCLUSION 

SAAM will affect the organization of the Center, a small tactical ten person 
simple organization. The LAN was a legacy system before SAAM was applied. SAAM 
decreased the phone bill by about an order of magnitude. Existing applications on the IP 
network became better. The Voice over IP system sounded like it was using a dedicated 
phone line through the switched circuits in the telephone company. Operational 
applications were enhanced, and now have information continuance. With the help of 
SAAM, the Center has become a fast twitch organization. Teams coagulated around 
solving problems in novel ways. Leadership is better able to assess the situation and 
respond in real time, if the active network has not responded already. 
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APPENDIX B. AUTHENTICATION PRIMER 


A. CRYPTOGRAPHY 

Cryptography is the science of protecting data by encryption. Cryptographic 
algorithms mathematically combine input plain text data and an encryption key to 
generate encrypted data, called cipher text. With a good cryptographic algorithm, it is 
computationally infeasible to reverse the encryption process and derive the plaintext data 
starting with only the cipher text. A decryption key is needed to perform the 
transformation. 

In traditional, secret (or symmetric) key cryptography, the encryption and 
decryption keys are identical and thus share sensitive data. Parties wishing to 
communicate with secret-key cryptography must securely exchange their 
encryption/decryption keys before they can exchange encrypted data. 

In contrast, the fundamental property of Public Key (PK) cryptography is that the 
encryption and decryption keys are different. Encryption with a public key encryption key 
is a "one-way" function. Plaintext turns into cipher text easily but the encryption key is 
irrelevant to the decryption process. A different decryption key (related but not identical 
to the encryption key) is needed to turn the cipher text back into plaintext. Thus, for PK 
cryptography every user has a pair of keys consisting of a public key and a private key. By 
making the public key available, it is possible for you to enable others to send you 
encrypted data that can only be decrypted using your private key. Similarly, you can 
transform data using your private key such that others can verify it originated from you. 
This latter capability is the basis for the digital signatures. 
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The separation between public and private keys in PK cryptography has allowed 
the creation of a number of new technologies. The most important of these are digital 
signatures, distributed authentication, secret key agreement via public key, and bulk data 
encryption without prior shared secrets. 

There are a number of well-known PK cryptographic algorithms. Some, such as 
RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography), are general 
purpose in the sense they can support all of the above operations. Others support only a 
subset of these capabilities. Some examples include the Digital Signature Algorithm 
(DSA, which is a part of the U.S. government’s Digital Signature’s Standard), which is 
useful only for digital signatures, and Diffie-Hellman (D-H), which is used for secret key 
agreement. 

The principle uses of PK cryptography and their operations can be summarized as 
case scenarios involving two imaginary clients, Bob and Alice. Assume that Bob and 
Alice can exchange information but do not have any prearranged shared secrets between 
them. The utilization of a Digital Signature (based on a mathematical transform that 
combines the private key with the data to be "signed" to such that: 

-Only someone possessing the private key could have created the digital signature 

-Anyone with access to the corresponding public key can verify the digital 
signature 

-Any modification of the signed data (even changing only a single bit in a large 
file) invalidates the digital signature. 

Digital signatures are themselves just data, so they can be transported along with 
the signed data they are intended to "protect". For example. Bob can create a signed e- 
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mail message to Alice and send the signature along with the message text, providing 
Alice the information required to verify the message origin. In addition, digital signatures 
provide a way to verify that data has not been tampered with (either accidentally or 
intentionally) while in transit from the source to the destination. Because of this, they can 
be exploited to provide a very high-assurance data integrity mechanism. 

B. AUTHENTICATION 

Public Key cryptography can be used to provide robust distributed authentication. 
Entity authentication guarantees that the sender of the data is the entity that the receiver 
thinks it is. One possible method involves the receiver, who is Alice in this example, 
sending a challenge to the sender, who is Bob in this example, encrypted with Bob’s 
public key. Bob then decodes this challenge with his private key and sends it back to 
Alice, proving that he has access to the private key associates with the public key used to 
encrypt the challenge. An alternative is for Alice to send a plaintext challenge to Bob. 
Bob then combines the challenge with other information, which is digitally signed. Alice 
then uses Bob’s public key to verify the signature and prove that Bob has the associated 
private key. The challenge makes this message unique and prevents replay attacks by a 
hostile third party. In either case, this is known as a "proof of possession" protocol 
because the sender is sender is proving that he has access to a particular private key. 

C. SECRET KEY AGREEMENT 

Another feature of PK cryptography is that it permits two parties to agree on a 
shared secret using public, and non-secure, communication networks. Basically, Bob and 
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Alice each generate a random number that will form half of the shared secret key. Bob 
then sends his half of the secret to Alice encrypted using her public key while Alice sends 
her half to Bob encrypted with his public key. Each side can then decrypt the message 
received from the other party, extract the half of the shared secret she did not generate 
herself, and combine the two halves to create the shared secret. Once the protocol is 
completed, the shared secret can be used for securing other communications. 

Another model to distribute secret key pairs is to use a trusted third party, such as 
a Kerberos Server. The Key Distribution Center (KDC) in Kerberos is a trusted host, and 
distributes session key pairs to two computers that want to talk with each other over an 
untrusted network. 

Given the plethora of security schemes available, a decision on which is the best 
one for SAAM must be made. 
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APPENDIX C. SELECTING AN AUTHENTICATION SYSTEM 


A decision must be made concerning the best authentication scheme to work with 
SAAM. In this chapter, several authentication schemes are explored. Analytical tools 
were employed to help filter through the wide range of authentication schemes that may 
apply. These tools included a decision matrix and a more complex expert system called 
Logical Decisions for Windows. The recommendation to kerberize RSVP is also relevant 
to the decision and is discussed in this chapter. 

A. DECISION MATRIX 

The simple matrix was the first tool we attempted. The matrix allowed us to 
organize the different authentication systems as a literature research tool, summarizing 
what we thought we needed to know. The different authentication schemes are listed 
horizontally across the top and are defined as follows: 


MITL 

- Man In The Loop 

Kerberos 

- Kerberos authentication system. 

PGP 

- Pretty Good Privacy 

CA 

- Certificate Authority 

EPSEC 

- IPsec 
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The attributes in question are listed in the left hand column, as shown below. 



MITL 

Kerberos 

PGP 

CA 

IPSEC 

Usability 

1 

9 

5 

7 

9 

Performance 

6 

9 

3 

5 

9 

Suitability 

1 

9 

2 

7 

9 

Monetary Cost 

1 

8 

9 

5 

8 

Interoperability 

1 

9 

7 

8 

9 

Total 

10 

44 

26 

32 

44 


Table 7. Simple Matrix 


The measures are listed in order of relative importance to SAAM. Each box 
receives a rank, on a scale from 1 to 10. These number assignments are arbitrarily set, 
based on our findings described below for each block. The bottom row shows the 
collective totals for each authentication scheme. 

B. DESCRIPTION OF MEASURES 

The following exploration and research outlines the evidence gathered to support 
the findings of fact. The thesis work is designed to provide a comprehensive 
authentication mechanism that will meet the following criteria for acceptance. 

1. Usability 

The ability for the investigated authentication scheme to meet “ease-of-use” 
functionality as well as the ability for the authentication scheme to appear “transparent” 
to the SAAM scheme of operations. 

2. Overhead on Routers/Servers 

The ability for the investigated authentication scheme to provide a small “foot 
print” in areas of hardware and bandwidth resources required for its implementation. 
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3. Suitability 


The ability for the investigated authentication scheme to match the environment in 
which the SAAM architecture is to be deployed. 

4. Monetary Cost 

The ability for the investigated authentication scheme to provide an effective 
authentication measure of assurance while not requiring a large monetary cost over-head 
or a re-occurring cost over a significant period of time, thus producing a negative cost 
over the life of the SAAM design, implementation, a continued service. 

5. Interoperability 

The ability for the investigated authentication scheme to be incorporated into the 
fabric of the SAAM architecture without a significant measure of performance loss in its 
efficiency or effectiveness providing authentication to the SAAM Enterprise. This is 
inter-SAAM operability. The ability for the investigated authentication scheme to hosts 
outside of the SAAM fabric, i.e. an RSVP request sent into the SAAM fabric, this is to 
ensure that SAAM does not exclude cross platform compatibility with current routers. 
This is intra-SAAM operability. 
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C. DESCRIPTION OF AUTHENTICATION SCHEMES 


1. “MITL” Man In The Loop 

Man in the loop (MITL) security uses a human being. An individual is 
responsible for conducting all security issues, including the transport of Recognition Keys 
throughout the SAAM Active Site. An analysis of the capabilities for the MITL process 
to have effectiveness within the SAAM enterprise when matched against the five 
evaluation criteria has been provided in the following paragraphs. 

a. MITL Usability 

The MITL agent would be required for the interaction and introduction of 
new cipher keys into the Server-to-Server authentication distribution as well as to 
introduce the keys into the router-to-router authentication. The MITL agent does not 
provide for ease of use and is not a transparent agent that can be easily modified. 

b. MITL Overhead on Routers/Servers 

The MITL agent would require a user interface that is consistent across the 
SAAM Enterprise in order to interact with SAAM authentication mechanism. The 
designing and user interface ease of use would require additional programming support 
during the initial development. Allocating resources for the GUI would constitute 
distribution of a resource that could otherwise be dedicated to the sole purpose of 
speeding up the authentication process or routing. The Java Virtual Machine could 
encounter a “frozen” thread during the processing of the table of distribution keys and 
therefore cause the entire SAAM system to become unpredictable. 
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c. MITL Suitability 

In the SAAM environment there will be numerous Servers interacting with 
each other throughout the SAAM enterprise. 

Within each SAAM regional area of responsibility there can be as many as 
forty or more SAAM routers interacting with each other. The MITL representative would 
be required to visit each and every device to insert the latest Recognition Key table for 
that period. This would be too time consuming. The expense of man-hours would 
outweigh the benefits received. 

d. MITL Monetary Cost 

The actual cost in dollars for the inclusion of the authentication in the 
SAAM system will vary dependent upon the selected authentication mechanism. A total 
software based solution would demonstrate a large up front cost but would avoid a 
redistributing cost that could escalate if it were an MITL agent. Cost savings cannot be 
realized with the MITL agent since it is a human factor and that the human factor cost is 
ever increasing in the world of technology. 

e. MITL Interoperability 

The MITL represents a physical human being interacting within the 
authentication process, to install the unique keys to be implemented within the Server-to- 
Server communications and the unique keys to be utilized in support of the regional 
SAAM routers. These keys must also have a time assignment for its value of eligibility 
within the SAAM Enterprise. 

If the MITL were to chosen, a guarded courier would have to deliver the 
new Recognition keys. 
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The dependency of an independent entity such as a MITL agent would 
mean that the entire authentication for the entire SAAM infrastructure would hinge on the 
MITL’s ability to execute his/her duties with clockwork precision throughout the SAAM 
enterprise. 

2. KERBEROS 

The Kerberos is a distributed authentication service that allows a client running on 
behalf of a principle (user) to provide its identity to a verifier (server) without sending 
data across the network that might allow an attacker or the verifier to subsequently 
impersonate the principal. Kerberos optionally provides integrity and confidentiality for 
data sent between the client and server. Kerberos was developed in the mid-80’s as part 
of MIT’s Project Athena, originally designed to prevent spoofed logins. Students could 
log onto servers across the network and avoid password intercept vulnerabilities. This 
protection is ideal for SAAM. Kerberos must be integrated with other parts of the SAAM 
system. It does not protect all messages sent between two computers; it only protects the 
messages from software that has been written to use it. The Kerberos authentication 
scheme uses a series of encrypted messages to prove to a verifier that a client is running 
on behalf of a particular process. The Kerberos protocol is based in part on the Needham 
and Schroeder authentication protocol, but with changes to support the needs of the 
environment for which it was developed. Among these changes are the use of timestamps 
to reduce the number of messages needed for basic authentication, the addition of a 
“ticket-granting” service to support subsequent authentication without re-entry of a 
service’s password, and different approaches to cross-realm authentication (authentication 
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of a principal registered with a different authentication server than the verifier). This is a 
simplified overview introduction to the Kerberos protocol; the paragraph by no means 
merits an all-exclusive overview of the Kerberos protocol and its volume of intricacies. 

a. Kerberos Usability 

The Kerberos measure of usability is measured by the ease of its use 
within the SAAM enterprise. Factors that require measurement to provide justification 
include the User Interface, and the ability to generate key tables and avoid redundancy of 
keys. 

b. Kerberos Overhead on Routers/Servers 

The level of overhead on SAAM routers is dependent on the measurement 
of the following metrics 

Time of Key Generation and Validation 

Processing of non-authenticated request 

Service processing requirements 

Level of difficulty in the coding process 

Extra memory needed to support authentication 

c. Kerberos Suitability 

Kerberos serving as an integral agent can be designed and engineered to 
work exclusively within the SAAM environment as a service. The Service can be 
incorporated as a new authentication module for ease of maintenance and modification 
should the needs and requirements change. In particular the lifespan of the key may 
change. Also, another measurement of suitability is the ability for the Kerberos agent to 
draw information from higher and parallel agents within the Enterprise. For example, the 
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SAAM router can connect the SAAM Server and also the designated Key Distribution 


Center (KDC) router simultaneously. 

d. Kerberos Monetary Cost 

The monetary cost incurred by the SAAM project can be measured via the 
following metrics: 

New Hardware required for authentication 

The additional man-hours to implement authentication 

e. Kerberos Interoperability 

The purpose of Kerberos is to provide authentication within the SAAM 
Enterprise of Server-to-Server communications as well as provide authentication uniquely 
amongst all member routers of an autonomous SAAM router region. The SAAM 
Enterprise can have an internal process agent designed into its core as its authentication 
regulator or the Kerberos key distribution system can be a third party application used by 
the SAAM infrastructure. Designing Kerberos into the SAAM Network will provide for 
a stream lined automated set of tools that can be leveraged to provide robust 
authentication. 


3. PGP 


a. PGP Usability 

PGP is relatively usable because it can be coded to run transparently 
before any messages are sent. However, PGP is slow because of the public key nature. It 
is not widely used in the commercial world. 
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b. PGP Overhead on Routers/Servers 

PGP is highly CPU intensive due to the public key calculations. 

c. PGP Suitability 

PGP is not really suitable to distribute keys within SAAM and change the 
key tables periodically, because of the number of keys required. Also, there is no central 
key table in PGP. Each process needs a key. There are cases in SAAM where two or 
more processes are running. For example, the regional SAAM server is a child to the 
parent Server. One key is needed for each process. The number of keys needed would be 
[n(n-l)]/2 with n processes. PGP is not scalable. 

d. PGP Monetary Cost 

PGP is free, concerning the acquisition cost only. For any Information 
System, acquisition cost is really only about one third of the entire life cycle cost. The 
technical support and user training components are not free. Cost is about the same for 
all the alternatives except for MITL. 

e. PGP Interoperability 

PGP can allow an edge router in SAAM to talk to other systems. For 
example, PGP can be used to authenticate an RSVP request for using the SAAM fabric. 
PGP is freeware and open source. Another router could be coded to use PGP also, but 
PGP is not a popular solution today for router authentication because of the key 
distribution and management problems involved. 
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4. 


CERTIFICATE AUTHORITY (CA) 


a. CA Usability 

A certificate authority is a scalable key distribution system, and a possible 
authentication solution for SAAM. The centralized key table makes for easier key 
management and distribution than the PGP web of trust model. The trust model is the 
problem, not the technology itself. A router can be coded to call the CA transparently 
before any messages are sent. A CA is slow because of the public key nature. However, 
the server-based architecture offloads some of the CPU burden from the routers. 

b. CA Overhead on Routers/Servers 

Public key creation is highly CPU intensive. This is only relevant when 
granting a certificate. Four messages must pass over the network with a CA system. 
[Stallings] 

c. CA Suitability 

A CA is not completely suitable to distribute keys within SAAM. It would 
be difficult to refresh the Recognition Keys periodically. The advantages of a CA include 
centralized key management and a hierarchical nature of KDC’s, which allow the CA to 
span all of SAAM fabric. This maps very well to SAAM hierarchy. 

d. CA Monetary Cost 

Third party vendors exist, such as Verisign, which charges $10 per 
certificate. This expense could work with this thesis research and may even work for the 
real SAAM system. It is likely that an in house SAAM CA would be less expensive in 
the long run. The monetary cost is just about the same for all alternatives except for 
MTTL. 
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e. CA Interoperability 

A CA can allow an edge router in SAAM to talk to other systems. For 
example, a CA can be used to authenticate an RSVP request for using the SAAM fabric. 
Any user that uses the same CA will be interoperable with SAAM. 

5. IP SECURITY 

IPsec is a layer three protocol that addresses the fundamental lack of security in 
the current Internet. IP next generation (IPng) was an exercise in the EETF to address the 
requirements for the next generation Internet. IPv6 was one of the resulting protocols, 
along with Classless Inter-Domain Routing (CEDR). IPv4 is the common internetworking 
protocol widely used on the Internet today. The security protocol has been extracted from 
IPv6 and can be used with IPv4. This security protocol with IPv4 is called IP Security 
(IPsec). IPsec uses an open standards architecture, allowing the specific encryption 
algorithm modules to be changed as CPU’s become faster and faster. 

IPsec requires public keys to operate, just as PGP does. A CA is an infrastructure 
to provide that public key. For this reason, CA does not compare well with public key 
technologies, such as PGP and IPsec. 

a. IPsec Usability 

Most routers on the market today now offer full support for IPsec. 
Configuration is said to be fairly simple. Likewise, IPsec could be coded into SAAM to 
be easy for the administrator to use. 

b. IPsec Overhead on Routers/Servers 
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Many administrators use IPsec for virtual private networks (VPN’s) to 
authenticate and encrypt all data traffic. IPsec was designed to run at layer 3, to encrypt 
all traffic. It may be possible to encrypt specific traffic associated with a network socket 
conversation, which would be application layer where SAAM runs. This is significant 
because SAAM only needs to authenticate signaling traffic, which runs at the application 
layer. Not all SAAM data traffic must be authenticated, and to do so would incur useless 
overhead. 

c. IPsec Suitability 

IPsec is fairly suitable because it is an open standard from the IETF, and it 
inherits all the benefits of operating at layer 3. That is to say, IPsec scales well, runs 
quickly, and without the knowledge of the administrator after it is configured to run. No 
manual intervention is needed after setup. 

d. IPsec Monetary cost 

As open source software, the ANSI C source code for IPsec can be free. 
Since there are several versions of encryption algorithms to choose from, companies will 
usually bundle IPsec as another service in a larger package, and charge money for the 
whole package. For example, Cisco IOS contains many different feature sets. Some 
versions of IOS contain IPsec capabilities. 

e. IPsec Interoperability 

Because it is an open standard, IPsec is interoperable. There is potential 
for some miscommunication between different devices. For example, it could be that 
IPsec in Microsoft windows 2000 might use a subtly different hash function in the 
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authentication header than the Cisco authentication header, rendering these two machines 
incompatible. It depends on how the standard is implemented. 

6. Matrix Results 

As you can see, the totals in the bottom of the matrix place Kerberos and IPsec in 
a tie for the best-fit authentication scheme. Further analysis was needed to differentiate 
between these two options. We chose to model our decision using decision support 
software. 

F. LOGICAL DESCISIONS FOR WINDOWS 

Logical Decisions for Windows (LDW) was used to assist in making this 
decision. LDW is a decision support system (DSS), which allows us to construct our 
decision model to consider all aspects relevant to the decision. LDW is based on utility 
theory. Provided that we setup the proper criteria with proper weights, the alternative 
with the highest overall utility is the best system. Goals are split into sub-goals, and 
logical measures are assigned to each sub goal. These metrics are all weighted 
appropriately. Trade-offs are made. The alternatives are applied to the model and data is 
finally entered for each category. This data entry is a little more quantitative than the 
matrix. LDW attempts to take qualitative knowledge and assign a quantity. The result is 
a recommendation from LDW for the best answer. The steps of logical decision analysis 
are: (1) structure the problem, (2) describe the alternatives, (3) review the preferences, 

and (4) rank alternatives and chose the best one. 
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1 . 


Structure the Problem 


a. Find the best authentication system 

The main goal is to find the best authentication system. This main goal 
consists of several sub-goals, such as maximize usability, maximize performance, 
etc. The sub goals are shown in boxes on the following figure. 


134 






Figure 38. Goals and Sub Goals in LDW Model 
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Notice that a new sub goal was added into the LDW model. IT-21 
compliance was considered to be important for SAAM. IT-21 compliance heavily 
influenced the final outcome of this model. 

Comments were added to each sub-goal and measures, describing the 
purpose of the sub-goal or measure. The reports below capture our thoughts during run¬ 
time of our analysis, displayed in the form of comments. 
a. Comments for Goals 


Goal 

Comment 

Best Authentication Goal 


Maximize Usability Goal 

Transparent to the user. How transparent to the 
user (administrator or IP Eng) is this 
Authentication mechanism? 

Maximize Performance Goal 

The least amount of overhead is (or the most 
performance, or efficiency) this a good 
authentication scheme. 

Maximize Suitability Goal 

Can this authentication mechanism run well 
with the SAAM system? 

Maximize Interoperability Goal 

Is this authentication scheme interoperable? 

1 . Within the SAAM system (inter-SAAM) 

2. Outside of the SAAM system. For 
example, an RSVP request may be sent 
in from a foreign host. 

Figure 39. 

Comments on Goals 

b. Comments for Measures 

Measure 

Comment 

Minimize Monetary Cost Measure 

Cheapest price wins. 

Training Requirement Measure 

KISS principle. Don’t want the administrator to 
spend too much time just learning the 
authentication method of SAAM. 

Setup Time Measure 

The system admin should be able to plug in the 
SAAM system and not have to worry about the 
authentication at all, ideally. Otherwise, he may 
tum it off. 

Maintenance Time Measure 

Ideally, once the authentication system is 
running, the system admin should not have to 
manually monitor it. It should run and fix itself 


136 







without any problems. 

Extra Computers Required Measure 

Memory Requirements Measure. Better to have 
minimal memory requirements in the router. “If 

I have to buy extra RAM just for authentication 
that is bad.” 

A core router's bottleneck is packet switching 
capacity. All else is peripheral. There is 
nothing particularly wrong with loading other 
tasks on the router except at the expense of core 
routing capacity. This is why offloading some 
tasks to a server is a benefit. 

Router CPU Cycles Requirement 
Measure 

Better to have minimal cpu cycles. For 
example, public key encryption calculations are 
usually more cpu intensive than one-way hash 
calculations. This concerns CPU cycles on 
Router only. IPsec relies on Router to generate 
session key, whereas Kerberos has KDC 
perform session key generation. 

Message Count Measure 

Better to have minimal number of messages sent 
during the handshake of authentication. This 
cuts down on bandwidth requirements. 

Message Size Measure 

Smaller authentication message size is better. 
This conserves bandwidth. 

Real Measure 

Is the authentication mechanism currently 
manufactured by vendors and sold today? If it 
is just an idea on paper, then it is not proven yet 
and very risky for us to try to implement. Is the 
authentication scheme currently used anywhere 
in the real world. 

Known Vulnerabilities Measure 

The Authentication Scheme should have the 
fewest known vulnerabilities possible. 

Server Based Measure 

Is the Authentication scheme server based? Can 
we use a central Key Distribution Center (KDC) 
with this scheme? 

Auto Key Dist. Measure 

The session key is automatically distributed. 

Scaleable Measure 

Can this authentication scheme scale from a 
prototype system with routers to the production 
Internet of millions? 

Programmable Measure 

Extensible. Can this authentication scheme be 
tailor fit into SAAM? That is, can this 
authentication scheme fit elegantly into the 
SAAM Architecture? 

Connection Oriented Measure 

Is the Authentication scheme connection 
oriented? That is to say, does this scheme allow 

A and B to authenticate while both are on line. 
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If the authentication scheme allows A to 
authenticate while offline, then that is bad. 

Platform Independent Measure 

Can this authentication scheme run on our 
prototype in Java on WinNT and also run on 
Unix, Linux, Cisco IOS, or any other OS? 

Supporting Vendors Measure 

The more the better, at least Microsoft must 
support this authentication scheme. Other 
considerations are WUGS ATM vendor, Cisco, 
Red Hat and Sun. 

Subject Specific Authentication 
Measure 

Does the authentication scheme allow any 
application to run or is the authentication 
scheme specific to one subject running at the 
application layer? Assume that the resident 
agents in SAAM will require authentication 
each time a new resident agent is run. 

IT-21 Compliant Measure 

Is the authentication mechanism compliant with 
the general Navy? 


Figure 40. Comments on Measures 


2. Map Qualitative Goals to Quantitative Measures 

The strength of LDW is that qualitative goals can be mapped to quantitative 
measures. For example, the goal to maximize usability contains issues such as training 
required, setup time, and maintenance time. Each of these measures can be quantified in 
units of hours. In cases where we still do not know how many hours a particular system 
will require, we set up units of high, medium and low, indicating over 100 hours, about 
50, and less than 20 hours respectively, so that we could compare one system directly to 
another. Quantifying the data input into LDW to some degree overcomes the uncertainty 
of our inputs in the matrix used above. 

Once we have a unit assigned to each measure, a utility is assigned to those units. 
A utility value of 1 is the best, while a utility value of 0 is the worst. Most utilities are a 
decimal value between zero and one. 
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The assessment summary report below shows what quantitative units were placed 
on each metric. This is how we get a number from a qualitative measure. 

Note that LDW utilities that are assessed directly in this table (not MUF’s) are 
shown in black and white. Data for the utilities with single measure utility functions 
(MUF’s) are not shown in the table below. For an explanation of what a MUF is, please 
see the LDW documentation. 


a. Common Units 






Auto Key Distribution 

Label 

Utility 


1. Yes 

1 


0. No 

0 




Connection Oriented 

1. Yes 

1 


2. No 

0.5 




ExtraComputers Requirements 

More than 4 
platforms. 

1 


2-4 platforms 

0.5 


1 platform 

0.1 




IT-21 Compliant 

1. Yes 

1 


0. No 

0 




Maintenance Time 

High 

0 


Medium 

0 


Low 

0 




Memory Required 

most preferred 
-0MB 

1.000 


mid preferred 
-16MB 

0.500 


least preferred 
-32MB 

0 




Programmable 

1. Yes 

1 


0. No 

0 




Real 

1. Yes 

1 
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Server^ Based _ 1. Yes _1 

0. No 0 



Figure 41. Assessment Summary Report 


Continuous Single-Measure Utility Functions 


Extra Computers Req’d 


least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

3.000 

0.000 

0.000 

1.000 

1.000 

0.250 

Known Vulnerabilities 






least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

2.000 

0.500 

0.000 

1.000 

1.000 

0.900 

1.000 

5.000 

0.000 

2.000 

0.500 

3.500 

0.100 
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Mem Req’d 


least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

32.000 

0.000 

0.000 

1.000 

16.000 

0.500 

Message Count 






least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

7.000 

0.000 

1.000 

1.000 

4.000 

0.500 

Message Size 






least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

1500.000 

0.000 

1.000 

1.000 

750.500 

0.500 

Minimize Monetary Cost 






least 

preferred 

range 

preferred 

level 

most 

preferred 

utility 

most 

preferred 

level 

mid¬ 

preferred 

utility 

mid¬ 

preferred 

level 

preferred 

utility 

0.000 

1000.000 

0.000 

0.000 

1.000 

500.000 

0.500 


Maximize Usability: a Utility function based on these tradeoffs: 
A B 


Setup Time 
(Hours) 


0 


Maintenance 

Time 0 5 

(Hrs/wk) 


Figure 42. Assessment Summary of MUF’s 
Notice how we considered the scalable requirement as separate from server based. 
These two variables are independent because scalability can be achieved without 
necessarily using a server-based solution. SAAM requires scalability to deploy to the 
global Internet. The server-based requirement is nice to have to match the current 
implementation of SAAM. 
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The supporting vendors requirement considered only the number of vendors that 


support the technology. We did not think in terms of cross vendor interoperability, which 
really should be considered. 


_ b. Weights _ 

_ a. Best Authentication _ 

A Utility function based on these tradeoffs: _ 

A B _ 

_ No interactions assessed _ 

_ b. Maximize Interoperability _ 

Utility function based on these tradeoffs: _ 

A B _ 

_ No interactions assessed _ 

_ c. Maximize Performance^ _ 

Utility function based on these tradeoffs: 

A B _ 

_ No interactions assessed _ 

_ d. Maximize Suitability _ 

Utility function based on these tradeoffs: _ 

A B _ 

_ No interactions assessed _ 

_ e. Maximize Usability _ 

Utility function based on these tradeoffs: __ 

A B _ 

_ Setup Time (Hours) 40 0 _ 

_ Maintenance Time (Hrs/wk) 0 _5_ 

_ No interactions assessed _ 

Figure 43. Assessment Summary Report 

Once the goals and sub goals are properly given measures with specific units, the 
next step to forming the decision model is to assign weights to the sub goals. Please see 
the tradeoff summary graph. 
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Minimize Monetary Cost Message\Sr 


orting Vendors 



Known Vulnerabilities 


ubject Specific Authentication 

9 

Server Based 


MUFs for Measures 

H Best Authentication □ Maximize Usability □ Maximize Performance 
□ Maximize Suitability □ Maximize Interoperability 


Preference Set = Authentication Mechanisms in SAAM 

Figure 44. Tradeoff Summary Graph 

The Tradeoff summary graph shows the percentage weights associated with each 
measure in the entire LDW model. 

Note that a MUF is a Multi-measure Utility Function. In this model, each sub 
goal can be considered a MUF. In the figure above, weights in a common parent goal, 
looking up the tree of a sub goal branch, are the same color. 

The same weights data is presented below in a report format. 
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Percentage Weights for Preference Set Authentication Mechanisms in SAAM 

Percentage Effective 

Measure 

Weight 

Weight 

Minimize Monetary Cost 

16.7 

16.7 

Training Requirements 

0.0 

0.0 

Setup Time 

1.9 

1.9 

Maintenance Time 

14.8 

14.8 

Extra Computers Req’d 

3.3 

3.3 

Mem Req’d 

3.3 

3.3 

Router CPU Cycles Req’d 

3.3 

3.3 

Message Count 

3.3 

3.3 

Message Size 

3.3 

3.3 

Real 

2.1 

2.1 

Known Vulnerabilities 

2.1 

2.1 

Server Based 

2.1 

2.1 

Auto Key Dist. 

2.1 

2.1 

Scaleable 

2.1 

2.1 

Programmable 

2.1 

2.1 

Connection Oriented 

2.1 

2.1 

Platform Independent 

8.3 

8.3 

Supporting Vendors 

8.3 

8.3 

Subject Specific Authentication 

2.1 

2.1 

IT-21 Compliant 

16.7 

16.7 


Figure 45. Weights Applied to Measures 


3. Describe the alternatives 

The next step is to determine what alternative systems should go into the model. 
We were not experts in the field of authentication and many systems were chosen based 
on general research on the Internet, and interviews with computer security experts. The 
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alternative systems chosen were then applied into the decision model we had constructed. 
The alternatives are listed below. 

a. MITL Alternative: Man In The Loop 

b. Kerberos Alternative: 

c. PGP Alternative: Pretty Good Privacy 

d. CA Alternative: Certificate Authority 

e. IPsec Alternative: 

f. SSL Alternative: Secure Socket Layer 

g. S/MIME Alternative: Secure MIME 

4. Review the Preferences 

The model now can be viewed as a large spreadsheet. Like the simple matrix 
example before this LDW discussion, we had to assign values to each box in this new 
spreadsheet. Again, the values assigned this time have undergone more scrutiny and 
structure. See the matrix view below. 
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Message 

Count 

Message 

Size 

Real 

Known Server 

Vulnerabilities Based 

Auto Key 
Dist. 

MITL 

1 

100 

1. Yes 

3 

0. No 

0. No 

Kerberos 

4 

100 

1. Yes 

0 

1. Yes 

1. Yes 

PGP 

2 

100 

1. Yes 

2 

0. No 

0. No 

CA 

5 

100 

1. Yes 

0 

1. Yes 

0. No 

IPsec 

3 

100 

1. Yes 

0 

0. No 

1. Yes 

SSL 

1 

100 

1. Yes 

1 

0. No 

0. No 

S/MIME 

1 

100 

1. Yes 

1 

0. No 

0. No 


Scaleable Programmable 

Connection 

Oriented 

Platform 

Independent 

Supporting 

Vendors 


MITL 

Medium - 
100,000 

0. No 

1. Yes 

1 platform 

Low 1 

Kerberos 

High- 

100,000,00 

0 

1. Yes 

1. Yes 

More than 4 
platforms. 

High 5 or 
more 

PGP 

Low - 100 

1. Yes 

2. No 

More than 4 
platforms. 

High 5 or 
more 

CA 

High - 
100,000,00 

0 

0. No 

1. Yes 

More than 4 
platforms. 

High 5 or 
more 

IPsec 

High- 

1. Yes 

1. Yes 

More than 4 

High 5 or 
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SSL 


S/MIME 


MITL 


Kerberos 


PGP 


CA 


IPsec 


SSL 


S/MIME 


100,000,00 


platforms. 

more 

0 




Medium - 


More than 4 

High 5 or 

100,000 

I.Yes I.Yes 

platforms. 

more 

Medium - 


More than 4 

High 5 or 

100,000 

1. Yes 2. No 

platforms. 

more 

Subject , T ?1 

Specific r .. 

Authentication ^ 



0. No 

0. No 



1. Yes 

1. Yes 



0. No 

0. No 



1. Yes 

0. No 



1. Yes 

0. No 



0. No 

0. No 



0. No 

0. No 




Figure 46. Data Entered into 

Model 



5. 


Rank Alternatives and Chose the Best One 


See the graphical result below, a final product of LDW. It becomes clear to use 
Kerberos for SAAM. 


Ranking for Best Authentication Goal 


Alternative 

Kerberos 

IPsec 

SSL 

S/MIME 

CA 

PGP 

MITL 


Preference Set = Authentication Mechanisms in SAAM 

Figure 47. LDW Result - Ranking for Best Authentication 


Utility 

0.795 [ 

0.588 [ 

0.565 [ 

0.554 [ 

0.545 [ 

0.530 [ 

0.205 [ 
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G. CONCURRENT RESULTS 


The IETF addresses the same situation we found ourselves in. The question of 
using IPSEC or Kerberos for a distributed network protocol was explored in detail. We 
arrived at the same decision to use Kerberos. A quote from RFC2747, Section 1.2, 
follows. 


Why not use the Standard IPSEC Authentication Header? One 
obvious question is why, since there exists a standard authentication 
mechanism, IPSEC ..., we would choose not to use it. 

This was discussed at length in the working group, and the use of 
IPSEC was rejected for the following reasons. The security associations 
in IPSEC are based on destination address. It is not clear that RSVP 
messages are well defined for either source or destination based security 
associations, as a router must forward PATH and PATH TEAR messages 
using the same source address as the sender listed in the SENDER 
TEMPLATE. RSVP traffic may otherwise not follow exactly the same 
path as data traffic. Using either source or destination based associations 
would require opening a new security association among the routers for 
which a reservation traverses. In addition, it was noted that neighbor 
relationships between RSVP systems are not limited to those that face one 
another across a communication channel. RSVP relationships across non- 
RSVP clouds ... are not necessarily visible to the sending system. These 
arguments suggest the use of a key management strategy based on RSVP 
router to RSVP router associations instead of IPSEC. From Ref. 
[RFC2747, sec 1.2] 


Our analysis developed as we learned more and more about IPsec and Kerberos. 
When we arrived at the LDW result to use Kerberos, we still had questions. However, it 
was reassuring to find that the IETF made the same decision as we did because RFC2747 
has undergone some degree of peer review. 
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APPENDIX D. SAAM INTEGRATED PROTOTYPE CODE 


A. SAAM CODE 


1. Packet Factory 


f * * 

* When instantiated to receive packets, the PacketFactory 

* thread waits until a SAAMPacket arrives, then it calls 

* the processPacket method. 

*/ 

public void run{){ 

System, out .print In (" I can call the scmSecurityManager from here'*); //pjs 
ScmSecMgr secMgr = new ScmSecMgr(false); 

while (true){ 

synchronized (inputLock){ 
if (inputQueue.isEmpty()){ 
try{ 

gui.sendText("Input packetfactory going to sleep 
inputFactoryAsleep = true; 
inputLock .wait () ,- 
inputFactoryAsleep = false; 

gui.sendText("Input packetfactory resumed"); 

} 


2. ScmSecMgr 


//'Module: 

//' Programmer: 
//'Date: 

//'Description: 


Security Manager 
Pete 

Tuesday 4Jun00 

THIS CODE WAS TRANSLATED FROM VB 
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//' Code module, now a Java Class, to declare global variables 

//' and the main procedure, which loads 

//' the main security manager form 

//'Make sure that the startup object is this module. 

//******★******************************* 

/ / *Name: scmSecMgr 
//*Authors: pjs 

//^Purpose: To handle all security functions for authenticaiton in SAAM. 
//**************************************// 

//do import statements here 

//We need to create the security package. 

package saam.security; 

//import a whole bunch of stuff, just like the Translator. 

import java.net.ServerSocket; 

import java.net.SocketException; 

import j ava.net.Socket; 

import java.net.InetAddress; 

import java.net.UnknownHostException; 

import java.util.TooManyListenersException; 

import java.util.Vector; 

import java.util.Hashtable; 

import java.io.IOException; 

import java.io.OutputStream; 

import java.io.Inputstream; 

import com.dstc.security.kerberos.Kerberos; 

import com.dstc.security.kerberos.KerberosContext; 

import com.dstc.security.kerberos.gssapi.*; 

import java.security.*; 

import j ava.io.*; 

import GSSClient; 

import GSSServer; 

//import saam.message.*; 
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//import saam.router.*; 

//import saam.util.SAAMRouterGui; 

//import saam.util.Array; 

//import saam.agent.ResidentAgent; 

//import saam.message.MessageProcessor; 
//import saam.event.*; 

//import saam.net.*; 

//import saam.control.*; 

public class ScmSecMgr { 

//** 

//* Instance variables 
//* 

//* State Variables 
//**/ 

GSSClient client; 

GSSServer server; 

//'Dimension the variables 

//'Variables to store the selected scenario 
/* 


Public 

Const 

giBOOTSCENE 

As 

Integer = 1 

Public 

Const 

giNEWJOINSCENE 

As 

Integer = 2 

Public 

Const 

giKEYREFRESHSCENE 

As 

Integer = 3 

Public 

giScenario 

As 

Integer 


*/ 

public static final int giBOOTSCENE = 1, 

giNEWJOINSCENE = 2, 
giKEYREFRESHSCENE = 3; 
public int giScenario = 1; 

//'Variables to store which host I am 
/* 

Public Const giKDC As Integer = 1 

Public Const giServer As Integer = 2 
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Public Const giRouterA As Integer = 3 
Public Const giRouterB As Integer = 4 


Public giWhoAml As Integer 

*/ 

public static final int giKDC = 1, 

giServer = 2, 
giRouterA = 3, 
giRouterB = 4; 

public int giWhoAml = 1; 

//'Variables to store my security state 
/* 

Public Const giNEWNODE As Integer = 1 

Public Const giTRUSTED As Integer = 2 

Public Const giRECOGNIZED As Integer = 3 

Public Const gilNVALID As Integer = 4 

Public giSecurityState As Integer 

*/ 

public static final int giNEWNODE = 1, 

giTRUSTED = 2, 

giRECOGNIZED - 3, 
gilNVALID = 4; 

public int giSecurityState = 1; 

//'Variables to store my message type 
/* 

Public Const giJOINREQUEST As Integer = 1 

Public Const giTRUSTSESSREQ As Integer = 2 

Public Const giTRUSTSESSRESP As Integer = 3 

Public Const giKTREQ As Integer = 4 

Public Const giKTRESP As Integer = 5 

Public Const giDCM As Integer = 6 

Public Const giUCM As Integer = 7 

*/ 

//'flow ID list in real SAAM will supercede this list here. 
//Where in SAAM can I find the list of flow ID's? 
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//Public giWorkingMsg 
//Never was used. 


As Integer 


//Public gstMsgContents As String //'Ctrl Msg sent out to SAAM 

public String gstMsgContents; 

//Note. The constructor must be placed physically before main(). 
public ScmSecMgr { boolean wantClient ){ 

// add DSTC to the list of crypto providers 
Provider dstc = new com.dstc.security.provider.DSTC() ; 

Security.addProvider(dstc); 

if (wantClient) { 
runClientO; 

} else { 

runServer(); 

} 

j * * 

/*Functions performed are to: 

/*1. Determine my security state. 

/*2. Send the appropriate message out, according to the state. 

/**/ 

//NodeState = pNodeState; 

System.out.println( "From inside the scmSecMgr constructor." ); 

/* 

//hard code for now. pjs. 
nodeState = 3; 

//determine my security state. 

if ( nodeState == SecurityManager.NEWNODE ){ 

System.out.println( " I am in a New Node State." ); 

} 

if { nodeState == SecurityManager.TRUSTED ){ 

System.out.println( " I am in a Trusted State." ); 
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} 


if ( nodeState == SecurityManager.RECOGNIZED ){ 

System, out .println ( " I am in a Recognized State." ); 

} 

if ( nodeState == SecurityManager. INVALID ){ 

System.out.println( " I am in an Invalid State." ); 

} //end if/thens 

//Send the appropriate msg out according to the state. 

if ( nodeState == SecurityManager .NEWNODE ) { 

System.out.println{ " I am sending a JoinRequest msg." ); 

//new saam. message. JoinRequest ( ).init( ); 

} 

if ( nodeState == SecurityManager .TRUSTED ){ 

System.out.println( " I am sending a KeyTableRequest msg." ); 

} 

if ( nodeState == SecurityManager.RECOGNIZED ){ 

System, out .println ( " I am sending a KeyTableResponse msg." ); 

} 

if { nodeState == SecurityManager. INVALID ){ 

System, out .println ( " I am invalid. I have no Node Secret and cannot join 
SAAM." ); 

} 

*/ 


} //end scmSecMgr constructor 

f * * 

* SecurityManager contains a main method to allow us to 

* run this class independent of the rest of SAAM temporarily 

* for diagnostics and testing only. When this is finished, we// 7 11 take the 

* main method out of here and leave main only in the Translator. 

* 

* A main method to enable command-line instantiation. 

*/ 
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/* 

Sub Main() 

//'Declare variables to initialize default states 
giScenario = 1 
giWhoAml = 1 
giSecurityState = 1 
//'Display the first form 
Load frmSecurityManager 
f rmSecurityManager. Show vbModal 
End Sub 
*/ 


public static void main{ String args[] ) { 

//giScenario = 1; 

//Produces a compile error. 

//Can't make a static reference to nonstatic variable giScenario in class 
saam.security.scmSecMgr 

//try putting these assignments on delcaration statements 
// giWhoAml = 1; 

// giSecurityState = 1; 

// add DSTC to the list of crypto providers 
Provider dstc = new com.dstc.security.provider.DSTC{); 

Security.addProvider(dstc); 

if (args.length != 1) { 

System.out.println( "Specify V'serverV or \"client\ M ” ); 
return; 

} 

if (args[0] .equalsIgnoreCase ("server") ) { 

System.out.println( "Running Server" ); 

ScmSecMgr secMgr = new ScmSecMgr(false) ; 

} 

else { 


155 






System.out.println( "Running Client" ); 

ScmSecMgr secMgr = new ScmSecMgr(true); 

} 

System.out.println( "I am inside the main method" ); 

System.out.println( "I was once VB but now am Java" ); 

} //main 

public void runClient(){ 

String server_host = "charlie.netl.cs.nps.navy.mil"; 
int server_port = 4321; 

String service = "gssserver@charlie.netl.cs.nps.navy.mil"; 

String userName = "gssclient"; 

String userPass = "gssclient"; 

String msg = "This is a test message"; 

msg = msg + ' \ 0' ; 

Kerberos kerb = Kerberos.getDefault{); 

try 

{ 

kerb.requestTGTWithPassword( userName, userPass ); 

// change the username in the context to reflect the name for 
// which the tgt was requested. Otherwise, the name shows the 
// name with which the user logged onto the local machine. 
KerberosContext context = kerb.getKerberosContextO; 
context.setUsername(userName); 

Socket socket = new Socket (InetAddress . getByName (server_hc>st) , 
server__port) ; 

BufferedOutputStream bos = new 
Buf feredOutputStream{socket. getOutputStream() ) ,- 
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DatalnputStream dis = new DatalnputStream(new 
BufferedlnputStream(socket.getlnputstream{))); 

GSSClient client = new GSSClient(dis # bos); 

client.establishContext(service); 

// display context flags 
client.displayStatus(); 

client.sendMessage(msg); 


} 

catch (GSSException e){ 

System.out.println("GSS-API error: " + e.getMessage()) 

} 

catch (Exception e){ 

System.out.println(e.getMessage()); 

} 

} 

public void runServer(){ 
int port = 4321; 

String service = ,, gssserver@charlie. netl. cs . nps . navy .mil 

GSSServer server = new GSSServer(port, service); 
server.run(); 

} 

} //end class 
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APPENDIX E. WEB RECOGNITION KEY PROTOTYPE CODE 


FILE: SAAMSERVERUPDATE.ASP 

<% 


’DB CONFIGURATION CONSTANTS 
DIM DB.CONNECTIONSTRING 

’DB_CONNECTIONSTRING = ,, DRIVER={MICROSOFT ACCESS DRIVER (*.MDB)};DBQ=” & 
SERVER.MAPPATH( M 7DB_SCRATCH.MDB M ) & 

’CONST DB_USERNAME = ’’USERNAME” 

’CONST DB_PASSWORD = ’’PASSWORD” 


’UNCOMMENT THE ABOVE TO USE THIS WITH AN ACCESS DATABASE PROGRAM OR USE THE BELOW 
WITH A SQL SERVER. 

’DB.CONNECTIONSTRING = APPLICATION(”SQLCONNSTRING”) & ”UED=” & 
APPLICATION(”SQLUSERNAME”) & ”;PWD=” & APPLICATION(”SQLPASSWORD”) & 

DB_CONNECTIONSTRING = ”DRIVER=SQL 

SERVER; SERVER=FELESERVER;UID=S A ;PWD=SQLINTHE99;APP=MICROSOFT DEVELOPMENT 
ENVIRONMENT;WSID=CIA2;DATABASE=SITESERVER3” 

DIM OBJRECORDSET 

SET OBJRECORDSET = SERVER.CREATEOBJECT(’’ADODB.RECORDSET’') 

OBJRECORDSET.OPEN ’’SERVERKDC”, DB_CONNECTIONSTRING, ADOPENKEYSET, ADLOCKPESSIMISTIC, 
ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 

%> 

<HTML> 

<!— #INCLUDE FILE=”ADOVBS.INC” -> 

<HEAD> 

<META HTTP-EQUIV=”CONTENT-TYPE” CONTENT-’'TEXT/HTML; CHARSET=WINDOWS-1252”> 
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<META NAME=”GENERATOR" CONTENT= "MICROS OFT FRONTPAGE 4.0"> 


<META NAME= , TROGro M CONTENT="FRONTPAGE.EDITOR.DOCUMENT"> 
<TITLE>DESTROY CIPHER PAGE</TITLE> 

</HEAD> 

<BODY BACKGROUND="IMAGES/BACKGROUND.GIF" TEXT="#800000"> 

<% 

>** lie***** * ** * **** * * * * * ******** **** 

FUNCTION CLEARCIPHERO 
OBJRECORDSET.MOVEFIRST 

IF NOT OBJRECORDSET.EOF AND NOT OBJRECORDSET.BOF THEN 
OBJRECORDSET.DELETE 
END IF 

OBJRECORDSET. CLOSE 
SET OBJRECORDSET = NOTHING 
END FUNCTION 


>* **** % a|e af« afe a|c ****************************************** ************ 

FUNCTION CLEARALLCIPHERO 
OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC DELETE FROM SERVERKDC", DB.CONNECTIONSTRING, 
ADOPENKEYSET, ADLOCKPESSIMISTIC, ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 5 CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
OBJRECORDSET.CLOSE 
SET OBJRECORDSET = NOTHING 
END FUNCTION 


)**************************************************************** 
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SELECT CASE REQUEST.FORM("OPT") 


CASE 0 

CLEARCIPHERO 
CASE 1 

CLEARALLCIPHERO 
END SELECT 

RESPONSE.REDIRECT("TOP_SAAMSERVER.ASP") 

%> 


</BODY> 


</HTML> 


FILE:TOPSAMSERVER.ASP 

<% 


’DB CONFIGURATION CONSTANTS 
DIM DB_CONNECTIONSTRING 

’DB_CONNECTIONSTRING = ”DRIVER={MICROSOFT ACCESS DRIVER (*.MDB)};DBQ=” & 
SERVER-MAPPATH("yDB_SCRATCH.MDB'') & 

’CONST DB.USERNAME = "USERNAME” 

’CONST DBJPASSWORD = "PASSWORD” 


’UNCOMMENT THE ABOVE TO USE THIS WITH AN ACCESS DATABASE PROGRAM OR USE THE BELOW 
WITH A SQL SERVER. 

’DB.CONNECTIONSTRING = APPLICATION(”SQLCONNSTRING”) & "UID=” & 
APPLICATIONCSQLUSERNAME”) & ";PWD=” & APPLICATION("SQLPASSWORD”) & 
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DB_CONNECTIONSTRING = "DRIVER=SQL 


SERVER;SERVER=FILESERVER;UID=SA;PWD=SQLINTHE99;APP=MICROSOFT DEVELOPMENT 
ENVIRONMENT;WSID=CIA2;DATABASE=SITESERVER3" 

DIM OBJRECORDSET 

SET OBJRECORDSET = SERVER.CREATEOBJECT("ADODB.RECORDSET") 

OBJRECORDSET.OPEN "SERVERKDC ", DB_CONNECTIONSTRING, ADOPENKEYSET, ADLOCKPESSIMISTIC, 
ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 

%> 

<HTML> 

<!— #INCLUDE FILE=" ADO VBS.INC'' -> 

<HEAD> 

<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1252"> 

<META NAME="GENERATOR" CONTENT="MICROSOFT FRONTPAGE 4.0"> 

<META NAME="PROGID" CONTENT="FRONTPAGE.EDITORDOCUMENT> 

<TITLE>SAAM AUTHENTICATION TECHNOLOGY PREVIEW</TITLE> 

<META NAME="AUTHOR" LANG="EN" CONTENT="LUIS E. VELAZQUEZ"> 

<META NAME="REPLY-TO" HTTP-EQUIV="REPLY-TO" CONTENT="VMAN@NEWSGUY.COM"> 

<META NAME="DESCRIPTION" HTTP-EQUIV="DESCRIPTION" CONTENT="SAAM SERVER TECHNOLOGIES" 
LANG="EN"> 

<META NAME="OWNER" CONTENT="VMAN@NEWSGUY.COM"> 

<META NAME="KEYWORDS" HTTP-EQUIV=:"KEYWORDS" CONTENT="SAAM SERVERS ROUTERS" 
LANG="EN"> 

<META NAME="COPYRIGHT" CONTENT="LUIS E. VELAZQUEZ"> 

<META HTTP-EQUIV="REFRESH" CONTENT="60; 

URL=HTTP:/AVWW.SQLNETWORKS.COM/THESIS/SIMULATION/TOP_SAAMSERVER.ASP"> 

<BASE TARGET="_SELF"> 

</HEAD> 

<% 
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SET FILEOBJECT = SERVER.CREATEOBJECT( M SCRIPTING.FILESYSTEMOBJECT M ) 
DIR = REQUEST.SERVERVARIABLES("SCRIPT__NAME M ) 

DIR = STRREYERSE(DIR) 

DIR = MID(DIR, INSTR(1, DIR, "/")) 

DIR = STRREVERSE(DIR) 

HITSFILE = SERVER.MAPPATH(DIR) & "VROUTER.TXT” 

ON ERROR RESUME NEXT 

SET INSTREAM= FILEOBJECT.OPENTEXTFILE (HITSFILE, 1, FALSE ) 

OLDHITS = TRIM(INSTREAM.READLINE) 

NEWHITS = OLDHITS + 1 

SET OUTSTREAM= FILEOBJECT.CREATETEXTFILE (HITSFILE, TRUE) 
OUTSTREAM. WRITELINE (NEWHITS) 

L=LEN(NE WHITS) 

1 = 1 

FOR I = I TO L 

NUM = MID(NE WHITS,1,1) 

DISPLAY = DISPLAY & ”<IMG SRC=’"7IMAGES l" & NUM & ”.GIF ,,,, >" 

NEXT 

%> 


<BODY BGCOLOR="#000080" TEXT="#008000” BACKGROUND="IMAGES/BACKGROUND.GIF"> 

<P ALIGN= ,f CENTER”xB>SAAM SERVER AND KDC</Bx/P> 

<P ALIGN=”CENTER '"><% RESPONSE.WRITE DISPLAY %></P> 
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?*********************************************** 

FUNCTION GENLETTERQ 
RANDOMIZEO 

LETTERNUMBER = INT(25*RND) 

SELECT CASE LETTERNUMBER 

CASED 

GENLETTER = "A" 

CASE 1 

GENLETTER =*B” 

CASE 2 

GENLETTER = "C" 

CASE 3 

GENLETTER = "D” 

CASE 4 

GENLETTER = "E" 

CASE 5 

GENLETTER = "F" 

CASE 6 

GENLETTER = "G" 

CASE 7 

GENLETTER = "H" 

CASES 

GENLETTER =T" 

CASE 9 

GENLETTER = "J” 

CASE 10 

GENLETTER = "K” 
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CASE 11 


GENLETTER = "L" 
CASE 12 

GENLETTER = M M r 
CASE 13 

GENLETTER = "N" 
CASE 14 

GENLETTER = "0 M 
CASE 15 

GENLETTER = "P" 
CASE 16 

GENLETTER = M Q" 
CASE 17 

GENLETTER = "R” 
CASE 18 

GENLETTER = ”S M 
CASE 19 

GENLETTER= ”T n 
CASE 20 

GENLETTER = "U" 
CASE 21 

GENLETTER = ’’V 1 ' 
CASE 22 

GENLETTER = H W" 
CASE 23 

GENLETTER = "X" 
CASE 24 

GENLETTER = "Y" 
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CASE 25 


GENLETTER = "Z" 

END SELECT 

END FUNCTION 

?********************************* 

FUNCTION GENNEWTICKET 
RANDOMIZEO 

FORMAT FOR NEW KEYS IS AS FOLLOWS 
1ST DIGIT ALPHANUMERIC 
... 2ND DIGIT ALPHABETICAL 
3RD DIGIT NUMERIC 
4TH DIGIT NUMERIC 
5TH DIGIT NUMERIC 
’— 6TH DIGIT ALPHABETICAL 
7TH DIGIT NUMERIC 
8TH DIGIT ALPHABETICAL 
9TH DIGIT NUMERIC 
10TH DIGIT NUMERIC 
’ 11TH DIGIT NUMERIC 
, - 12TH DIGIT NUMERIC 

KEYOPTION = INT(2*RND) 

SELECT CASE KEYOPTION 
CASE 0 
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GENNEWTICKET = CSTR(INT(9*RND)) & GENLETTERO & CSTR(INT(9*RND)) & CSTR(INT(9*RND)) & 
CSTR(INT(9*RND)) & GENLETTERO & CSTR(INT(9*RND)) & GENLETTERO & CSTR(INT(9*RND)) & 
CSTR(INT(9*RND)) & CSTR(INT(9*RND)) & CSTR(INT(9*RND)) 

CASE 1 

GENNEWTICKET = GENLETTERO & GENLETTERO & CSTR(INT(9*RND)) & CSTR(INT(9*RND)) & 
CSTR(INT(9*RND)) & GENLETTERO & CSTR(INT(9*RND)) & GENLETTERO & CSTR(INT(9*RND)) & 
CSTR(INT(9*RND)) & CSTR(ENT(9*RND)) & CSTR(INT(9*RND)) 

END SELECT 

END FUNCTION 

)***** ******* ********* ****** ****** 

FUNCTION ADDNEWTICKETS(X) 

DIM TICKETNUMBER 
RANDOMIZEO 

SESSIONCNEWTICKETOKAY”) = TRUE 
TICKETNUMBER = CSTR(GENNEWTICKETO) 

OBJRECORDSET.ADDNEW 

’OBJRECORDSET.FIELDSf’CIPHERTEXT") = CSTR(TICKETNUMBER) 
OBJRECORDSET.FIELDS(”CIPHERKEY”) = TICKETNUMBER 
OBJRECORDSET.UPDATE 
END FUNCTION 

********************************** 

FUNCTION UPDATEACTIVECIPHER 

OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC WHERE ACTIVE=1 AND EXPIRED=0”, DB_CONNECTIONSTRING, 
ADOPENKEYSET, ADLOCKPESSIMISTIC, ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
’RESPONSE.WRITE OBJRECORDSET.FIELDS(”CIPHERKEY”) 
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OB JRECORDSET.FDELDS(" ACTIVE") = 0 
OBJRECORDSET.FIELDS("EXPIRED”) = 1 
OB JRE CORDSET.UPD ATE 
OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC WHERE ACTIVE=0 AND EXPIREEM)", DB_CONNECTIONSTRING, 
ADOPENKEYSET, ADLOCKPESSIMISTIC, ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 

OBJRECORDSET.FIELDS("ACTIVE M ) = 1 

OBJRECORDSET.FIELDS("EXPIRED") = 0 

OBJRECORDSET.UPDATE 

OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC", DB„CONNECTIONSTRING, ADOPENKEYSET, ADLOCKPESSIMISTIC, 
ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
END FUNCTION 

********************************** 

FUNCTION GETACTIVECEPHER 

OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC WHERE ACTIVEX", DB_CONNECTIONSTRING, ADOPENKEYSET, 
ADLOCKPESSIMISTIC, ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
RESPONSE. WRITE OBJRECORDSET.FIELDS("CU»HERKEY”) 

OBJRECORDSET.CLOSE 

OBJRECORDSET.OPEN "SERVERKDC", DB_CONNECTIONSTRING, ADOPENKEYSET, ADLOCKPESSIMISTIC, 
ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
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END FUNCTION 


» * ***** * * ** * * * ****** * ******* * ************** **** ***************** * 

>* **** **** ********* *************************************** ******* 

’* VARIABLES 

’* X | HOW MANY TICKETS TO GENERATE 

’* KK | COUNTER TO INCREMENT AS KEYS ARE GENERATED 

’* YY | HOW MANY RECORDS WERE IN THE DATABASE PRIOR TO ACTUAL GENERATION 
IRECORDCOUNT = OBJRECORDSET.RECORDCOUNT 
DIM X, KK, YY, IRECORDCOUNT 
X =0 

KK = 100 

>**************************************************************** 

IF IRECORDCOUNT = 0 THEN 

’SESSIONC’NEWTICKETOKAY”) = FALSE 
WHILE IRECORDCOUNT < KK 

RESPONSE.WRITE ’’CREATING CIPHER TEXT FOR THE MASTER SERVER VIA THE KDC” 

%><BR><% 

RESPONSE.WRITE ’’TOTAL KDC RECORD COUNT” & IRECORDCOUNT %><BR> <% 
ADDNEWTICKETS(X) 

RESPONSE.WRITE ’RECORD ADDED VERIFYING INTEGRITY’’ %><BR><% 
IRECORDCOUNT= IRECORDCOUNT +1 

WEND 

OBJRECORDSET.FIELDS(’ACTIVE ”) = 1 

OBJRECORDSET.UPDATE 

RESPONSE.WRITE ’’CIPHER KEY ACTIVATED” 

END IF 
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>**************************************************************** 


’ LOOP THROUGH RECORDSET AND DISPLAY RESULTS 
OBJRECORDSET.MOVEFIRST 
IF NOT OBJRECORDSET.EOF THEN 
UPDATEACTIVECIPHERO 
OBJRECORDSET.MOVEFIRST 


%> 

<P ALIGN="CENTER”> <FORM ACTIONS’RIGHTPANE.ASP” METHOD=”GET”> 

<SELECT NAME="ID" SIZE=’T> 

<OPTION><%= GETACTIVECIPHERO %></OPTION> 

<% 

9 CONTINUE UNTIL WE GET TO THE END OF THE RECORDSET. 

DO WHILE NOT OBJRECORDSET.EOF 

%> 

<OPTION VALUE=”<%= OBJRECORDSET.FIELDS(”ID”) %>”><%= OBJRECORDSET.FIELDS( M CIPHERKEY”) 
& ”, M & OBJRECORDSET.FIELDS(''EXPIRED’') & ”, ” & OBJRECORDSET.FEELDS(”ACTIVE M ) %></OPTION> 


<% 

9 GET NEXT RECORD 
OBJRECORDSET.MOVENEXT 
LOOP 

%> 

</SELECT> 

<P ALIGN="CENTER”xI><B> SAAM. 2 MASTER ROUTER KDC UPDATE</Bx/Ix/P> 
</FORM> 

<% 
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END IF 


OBJRECORDSET.CLOSE 

%> 


<!-WEBBOT BOT="GENERATEDSCRIPT" PREVIEW=" " STARTSPAN -xSCRIPT 
LANGUAGE="JAVASCRIPT"x!-- 

FUNCTION FRONTPAGE_FORM2_VALIDATOR(THEFORM) 

{ 


IF (THEFORM.OPT.SELECTEDINDEX < 0) 

{ 

ALERTC'PLEASE SELECT ONE OF THE VCIPHER DELETE OPTIONV' OPTIONS."); 
THEFORM.OPT.FOCUSO; 

RETURN (FALSE); 

} 

RETURN (TRUE); 

} 

//--></SCRIPT><! -WEBBOT BOT="GENERATEDSCRIPT" ENDSPAN -xFORM METHOD="POST" 
ACTION=”TOP_SAAMSERVERUPDATE.ASP" NAME="FRONTPAGE_FORM2" ONSUBMIT="RETURN 
FRONTPAGE_FORM2_VALIDATOR(THIS)"> 

<P ALIGN="CENTER"xINPUT TYPE="SUBMIT" VALUE="SUBMIT" NAME=”Bl"xBx!-WEBBOT 
BOT="VALIDATION" S-DISPLAY-NAME=”CIPHER DELETE OPTION" B-VALUE-REQUIRED="TRUE" 
-xSELECT SIZE="1" NAME="OPT"> 

<OPTION VALUE="0">DELETE SINGLE CIPHER</OPTION> 
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cOPTION VALUE="UNDELETE ALL CIPHERS</OPTION> 
</SELECT>UPDATE 
MASTER CIPHER</B></P> 

</FORM> 


</BODY> 


</HTML> 

FELE:TOP_SAAMSERVERUPDATE.ASP 

<% 


’DB CONFIGURATION CONSTANTS 
DIM DB_CONNECTIONSTRING 

’DB_CONNECTIONSTRING = "DRIVER={MICROSOFT ACCESS DRIVER (*.MDB)};DBQ=" & 
SERVER.MAPPATH( , VDB_SCRATCH.MDB n ) & 

’CONST DB_USERNAME = * 'USERNAME'' 

’CONST DB_PASSWORD = 'PASSWORD’’ 


’UNCOMMENT THE ABOVE TO USE THIS WITH AN ACCESS DATABASE PROGRAM OR USE THE BELOW 
WITH A SQL SERVER. 

’DB_CONNECTIONSTRING = APPLICATION("SQLCONNSTRING") & ”UID= M & 
APPLICATIONC’SQLUSERNAME”) & ";PWD=” & APPLICATION(”SQLPASSWORD ") & 

DB_CONNECTIONSTRING = "DRIVER=SQL 

SERVER;SERVER=FILESERVER;UID=SA;PWD=SQLINTHE99;APP=MICROSOFT DEVELOPMENT 
ENVIRONMENT;WSID=CIA2;DATABASE=SITESERVER3" 

DIM OBJRECORDSET 
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SET OBJRECORDSET = SERVER.CREATEOBJECT("ADODB.RECORDSET") 


OBJRECORDSET.OPEN "SERVERKDC", DB.CONNECTIONSTRING, ADOPENKEYSET, ADLOCKPESSEMISTIC, 
ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 

%> 

<HTML> 

<!— #INCLUDE FILE="ADOVBS.INC” --> 

<HEAD> 

<META HTTP-EQUIV =''CONTENT-TYPE'’ CONTENTS TEXT/HTML; CHARSET=WINDOWS-1252”> 

<META NAME='’GENERATOR'' CONTENT="MICROSOFT FRONTPAGE 4.0"> 

<META NAME^'PROGID" CONTENT= ,, FRONTPAGE.EDITOR.DOCUMENT”> 

<TITLE>DESTROY CIPHER PAGE</TITLE> 

</HEAD> 

<BODY BACKGROUND="IMAGES/BACKGROUND.GIF M TEXT="#800000"> 

<% 

********************** ************ 

FUNCTION CLEARCIPHERO 
OBJRECORDSET.MOVEFIRST 

IF NOT OBJRECORDSET.EOF AND NOT OBJRECORDSET.BOF THEN 
OBJRECORDSET.DELETE 

END IF 

OBJRECORDSET.CLOSE 
SET OBJRECORDSET = NOTHING 
END FUNCTION 


***************************************************************** 

FUNCTION CLEARALLCIPHERO 
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OBJRECORDSET.CLOSE 


OBJRECORDSET.OPEN "SERVERKDC DELETE FROM SERVERKDC", DB_CONNECTIONSTRING, 
ADOPENKEYSET, ADLOCKPESSIMISTIC, ADCMDTABLE 

OBJRECORDSET.CACHESIZE = 15 ’ CUTS DOWN ON ROUND TRIPS TO OUR SQL SERVER 
OBJRECORDSET.CLOSE 
SET OBJRECORDSET = NOTHING 
END FUNCTION 




SELECT CASE REQUEST.FORM("OPT") 

CASE 0 

CLEARCIPHERO 
CASE 1 

CLEARALLCIPHERO 
END SELECT 

RESPONSE.REDIRECTrTOP_SAAMSERVER.ASP”) 

%> 


</BODY> 


</HTML> 
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APPENDIX F. VISUAL BASIC PROTOTYPE CODE 


A. FRMSECURITYMANAGER 


'm. Security Manager User Interface. Assume SAAM is 




• aecuity orate - 


<* New Node 
r Trusted 
C Recognized 
C Invalid 


Security State Description 

New Node state means that I possess a Node 
Secret, but no Trusted Session Key and no 
Recognition Key Table. 




- Security Prototype Initializer 
r- Who Am I?- 

a KDC 
C Server 
i C RouterA 
I I C RouterB 


- What scenario should run?— 

(• Boot 
C New Join 

C Recognition Key Refresh 


j Receive Message \ 

Quit 

i..-.-.-J 



Send Message 


Private Sub cmdQuit_Click() 
End 


End Sub 


Private Sub cmdRcvMsg_Click() 
’ go to the Process message form 
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Me.Hide 


frmStatusFrame.Show vbModless 
frmRcvMsg.Show vbModal 
End Sub 

Private Sub cmdSendMsg_Click() 

Update the Status frame with the selections made by the user, SAAM himself 
If optBoot.Value = True Then 
giScenario = giBOOTSCENE 
Debug lines added pjs. 

Print giBOOTSCENE 
Print giScenario 

Elself optNewJoin.Value = True Then 
giScenario = giNEWJOINSCENE 
Elself optRecKeyRefresh.Value = True Then 
giScenario = gi KE YREFRES HS CENE 
Else 

MsgBox "Please make scenaio selection", vbOKOnly, "Oops" 

End If 


’ go to the Choose Message form 
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Me.Hide 


frmStatusFrame.Show vbModless 
frmChooseMsg.Show vbModal 
End Sub 

Private Sub Form_Activate() 

Try to force a refresh of that status frame. 
’frmStatusFrame.Hide 

End Sub 

Private Sub optBoot_Click() 

’Store that we will run the SAAM network boot scenario 

giScenario = giBOOTSCENE 
End Sub 

Private Sub optInvalid_Click() 

Describe invalid state 

giSecurityState = gilNVALID 
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IblSecStDescription.Caption = "Invalid state means that my Node Secret has been 

revoked from the KDC. If the enemy has compromised me, they will not be able to use 

me for much longer." 

imgRed.Visible = False 

imgYellow. Visible = False 

imgGreen.Visible = False 

imglnvalid.Visible = True 

End Sub 

Private Sub optKDC_Click() 

’store that who i am is the KDC 

giWhoAml = giKDC 

End Sub 

Private Sub optNewJoin_Click() 

’store that we will run the new join scenario 

giScenario = gi NEW JOINS CENE 
End Sub 

Private Sub optNewNode_Click() 
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’Store the security state, Describe the New Node State, display appropriat image. 

giSecurityState = giNEWNODE 

lblSecStDescription.Caption = "New Node state means that I possess a Node Secret, but 

no Trusted Session Key and no Recognition Key Table." 

imgRed.Visible = True 

imgYellow. Visible = False 

imgGreen.Visible = False 

imglnvalid.Visible = False 

End Sub 

Private Sub optRecKeyRefresh_Click() 

’store that we will run the recognition key refresh scenario 

giScenario = giKEYREFRESHSCENE 
End Sub 

Private Sub optRecognized_Click() 

Describe Recognized Node State 

giSecurityState = giRECOGNIZED 

lblSecStDescription.Caption = "Recogninzed state means that I possess a valid 
Recognition Key and I can complete authentication in SAAM now." 
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imgRed. Visible = False 
imgYellow. Visible = False 
imgGreen. Visible = True 
imglnvalid. Visible = False 
End Sub 

Private Sub optRouterA_Click() 
’store that i am routerA 

giWhoAml = giRouterA 
End Sub 

Private Sub optRouterB_Click() 
’store that I am routerB 

giWhoAml = giRouterB 
End Sub 

Private Sub optServer_Click() 
’store that i am the saam server 

giWhoAml = giServer 
End Sub 
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Private Sub optTrusted_Click() 

Describe the Trusted State 

giSecurityState = giTRUSTED 

lblSecStDescription.Caption = "Trusted state means that I a valid Trusted Session Key, 

but no Recognition Key Table." 

imgRed.Visible = False 

imgYellow.Visible = True 

imgGreen.Visible = False 

imglnvalid.Visible = False 

End Sub 
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FRMSTATUSFRAME 


;5^sr,^:X'ix—•;'• .. .. 


Who Am I 
Scenario jNascient Network 


JSecurify State {New Node 


Processing StatasWaiting to receive a msg.. 


Private Sub Form_Activate() 

’Get and set the values of whoami and all the other output labels 
lbl Who AmlJVal. Caption = gi Who Ami 
If giWhoAml = 1 Then 

lbl WhoAmI_V al .Caption = "KDC" 

El self giWhoAml = 2 Then 

lbl Who AmI_Val.Caption = "Server" 

Elself giWhoAml = 3 Then 

lbl Who AmI_V al. Caption = "RouterA" 

Elself giWhoAml = 4 Then 
IblWhoAmLVal.Caption = "RouterB" 


Else: MsgBox "I do not know who I am", vbExclamation, "Oops 





If giSecurityState = 1 Then 
lblSecState_Val.Caption = "New Node" 
’set traffic light 
imgRed.Visible = True 
imgYellow.Visible = False 
imgGreen.Visible = False 
imglnvalid.Visible = False 

Elself giSecurityState = 2 Then 
lblSecState_Val.Caption = "Trusted" 
imgRed.Visible = False 
imgYellow.Visible = True 
imgGreen.Visible = False 
imglnvalid.Visible = False 

Elself giSecurityState = 3 Then 
lblSecState_Val.Caption = "Recognized" 
imgRed.Visible = False 
imgYellow.Visible = False 
imgGreen. Visible = True 
imglnvalid.Visible = False 
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Elself giSecurityState = 4 Then 
lblSecStateJVal.Caption = "Invalid" 
imgRed.Visible = False 
imgYellow. Visible = False 
imgGreen.Visible = False 
imglnvalid.Visible = True 

Else: MsgBox "I do not know what my security state is", vbExclamation, 

"Oops" 

End If 


If giScenario = 1 Then 

lblScenario_Val.Caption = "Nascient Network" 

Elself giScenario = 2 Then 
lblScenario_Val.Caption = "New Join" 

Elself giScenario = 3 Then 

lblScenario_Val.Caption = "Recognition Key Refresh" 

Else: MsgBox "I do not know what scenario to run", vbExclamation, "Oops" 
End If 


’Give a few processing status messages for common situations 
If giWhoAml = giRouterB And giSecurityState = giNEWNODE And giScenario 
= giNEWJOINSCENE Then 
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lblProcsStatus_Val.Caption = "I just got a DCM. Preparing my Join Request 

msg..." 

Elself giWhoAml = giRouterA And giSecurityState = giNEWNODE And 
giScenario = giNEWJOINSCENE Then 

lblProcsStatus_Val.Caption = "Waiting for a Join Request..." 

Elself giWhoAml = giServer And giSecurityState = giNEWNODE And 
giScenario = giNEWJOINSCENE Then 

lblProcsStatus_Val.Caption = "Waiting for signed UCM’s" 

Elself giWhoAml = giKDC And giSecurityState = giNEWNODE And giScenario 
= giNEWJOINSCENE Then 

lblProcsStatus_Val.Caption = "Waiting for Trusted Session Request msg..." 
End If 

If giWorkingMsg = 1 Then 

lblWorkingMsg.Caption = "Join Request" 

Elself giWorkingMsg = 2 Then 
lblWorkingMsg.Caption = "Trusted Session Request" 

End If 


lblWorkingMsg.Caption = "Test" 


’cmt to break here 
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End Sub 


C. FRMCHOOSEMESSAGE 



Private Sub cboMsgList_Change() 


TrmStatusFrame.lblWorkingMsg.Caption = cboMsgList.ItemData 


If cboMsgList.Text = "JoinRequest" Then 
’ giWorkingMsg = 1 
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End If 


frmStatusFrame.Hide 
frmStatusFrame.Show vbModeless 

End Sub 

Private Sub cmdBack_Click() 

Me.Hide 

’force a refresh of the status frame 
frmStatusFrame.Cls 

frmSecurityManager.Hide 
frmSecurityManager.Show vbModal 
End Sub 

Private Sub cmdNext_Click() 

Me.Hide 

frmSignDecision.Show vbModal 
End Sub 
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Private Sub cmdQuit_Click() 


End 

End Sub 

Private Sub Form_Activate() 

’Run the Status Frame as a separate form that is always on top 
In the upper right hand comer 

If gbSendingKeyTable = True Then 

gstMsgContents = "This is the Encrypted Key Table..." 

End If 

End Sub 
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D. FRMSIGNDECISION 



aasfrtj ; j 33 gg i^a jj 


1 SDAuthcnUcatioo-Mc.,.j ^ Project! - Mfcrwoft ...j ^]WP3.con>>Sato» 


. —— 


Dim mbSignDecision As Boolean ’stores sign or don’t sign this message 


Private Sub cmdBack_Click() 


Me.Hide 

frmChooseMsg.Hide 
frmChooseMsg.Show vbModal 
End Sub 


Private Sub cmdNext_Click() 
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frmConstructMsg.Show vbModal 


End Sub 

Private Sub cmdQuit_Click() 

End 

End Sub 

Private Sub Form_Activate() 

’get the name of the message chosen to send and display it. 

lblMsgChosen. Caption = frmChooseMsg.cboMsgList.Text 
If gbSendingKeyTable = True Then 

’gstMsgContents = "This is the Encrypted Key Table..." 
IblMsgChosen.Caption = "KeyTableResponse" 

End If 


Make sign decision. Knowledge Engine. 
mbSignDecision = True Default to require signing. 

If frmChooseMsg.cboMsgList.Text = "JoinRequest" Then 
’ mbSignDecison = False 






IblSignDecision.Caption = "False" Display signing decision results 
Elself lblMsgChosen.Caption = "KeyTableResponse" Then 
’ mbSignDecison = False 

IblSignDecision.Caption = "False" Display signing decision results 
’Add all the msgs that do NOT require signing here. 

End If 


If frmChooseMsg.cboMsgList.Text = "TrustedSessionRequest" Then 
IblSignDecision.Caption = "True" Display signing decision results 
End If 


End Sub 
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E. 


FRMCONSTRUCTMESSAGE 



Message Chosen 


Source Address 

Destination Address 

Flow ID 

Message Contents 


Packet Structure - 


2.3 


2.4 


Text! 


72GKEYTABLE 


JnjxJ 


p Encrypt the Key T able if you need- 


Trsuted Session Key Value |^7f^jF^^KIFWir7" 
Key Table Value: 


jVMAN! Show me the money! 


Encrypted KeyT able 
Value: 


THEFATMANWALKSALONE. 


If Authentication is Needed I will compute these for you- 
Key Index 


lABCD 


Recognition Key 
MAC * hash output 


SZCZEPANKiEWICZ 


MAC here 


Key Index MAC 
JaBCD (MAC here (SZCZEPANKIE j ZA 


Recognition Key Destination Address Source Address Flow ID 

““ 0 — 


jTextl 


Message Contents 
jTHEFATMANWALKSAL 


Back 


Quit 


Next 


Dim mstSourceAddr As String 
Dim mstDestAddr As String 
Dim mstMsgContents As String 


Private Sub cmdBack_Click() 


Me.Hide 

frmSignDecision.Show vbModal 
End Sub 
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Private Sub cmdNext_Click() 


Me.Hide 

frmSendMsgNow.Show vbModal 

End Sub 

Private Sub cmdQuit_Click() 

End 

End Sub 

Private Sub Form_Activate() 

If frmSignDecision.lblMsgChosen = "JoinRequest" Then 
txtMsgType.Text = "JoinRequest" 
mstSourceAddr = 
txtSrcAddr.Text = mstSourceAddr 
mstDest Addr = " 1.. 1" 
txtDestAddr.Text = mstDestAddr 
mstMsgContents = " LETMEJOIN " 
txtMsgContents.Text = mstMsgContents 
lblFlowID.Visible = False 
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txtFlowID.Visible = False 


lblKeylndex.Visible = False 
txtKeylndex.Visible = False 
IblMsgAC.Visible = False 
txtMsgAC.Visible = False 
lblRecognitionKey.Visible = False 
txtRecognitionKey.Visible = False 
lblFloE). Visible = False 
txtFloDD. Visible = False 
fraEncryptKeyTbl.Visible = False 
fralfAuthNeeded. Visible = False 
txtMessageContents.Text = mstMsgContents 
End If 


If frmSignDecision.lblMsgChosen = "TrustedSessionRequest" Then 
txtMsgType.Text = "TrustedSessionRequest" 
mstSourceAddr = "131.120.8.155" 
txtSrcAddr.Text = mstSourceAddr 
mstDestAddr = "131.120.9.66" 
txtDestAddr.Text = mstDestAddr 
mstMsgContents = " TRUSTME " 
txtMsgContents .Text = mstMsgContents 


lblFlowID.Visible = True 





txtFlowID. Visible = True 


lblKeylndex.Visible = True 
txtKeylndex. Visible = True 
lblMsgAC.Visible = True 
txtMsgAC.Visible = True 
lblRecognitionKey. Visible = True 
txtRecognitionKey. Visible = True 
lblFloID.Visible = True 
txtFloED. Visible = True 
fraEncryptKeyTbl.Visible = False 
fralfAuthNeeded.Visible = True 
txtKeylndex.Text = txtKI.Text 
txtMsgAC.Text = txtMAC.Text 
txtRecognitionKey.Text = txtRecKey.Text 
txtFloDD.Text = txtFlowED.Text 
txtMessageContents.Text = mstMsgContents 
End If 


If frmSignDecision.lblMsgChosen = "KeyTableResponse" Then 
txtMsgType.Text = "KeyTableResponse" 
mstSourceAddr = "2.3" 
txtSrcAddr.Text = mstSourceAddr 
mstDestAddr = "2..4" 
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txtDestAddr.Text = mstDestAddr 


mstMsgContents = " 720KEYTABLE ” 
txtMsgContents.Text = mstMsgContents 
IblFlowID.Visible = True 
txtFlowED.Visible = True 
lblKeylndex. Visible = True 
txtKeylndex.Visible = True 
lblMsgAC.Visible = True 
txtMsgAC.Visible = True 
IblRecognitionKey.Visible = True 
txtRecognitionKey.Visible = True 
lblFloDD.Visible = True 
txtFloID.Visible = True 
fraEncryptKeyTbl.Visible = True 
fralfAuthNeeded.Visible = True 
txtKeylndex.Text = txtKI.Text 
txtMsgAC.Text = txtMAC.Text 
txtRecognitionKey.Text = txtRecKey.Text 
txtFloID.Text = txtFlowID.Text 

txtMessageContents.Text = txtEncryptedKeyTable.Text 
End If 


Build Packet structure before passing back to SAAM. 
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txtDestinationAddr.Text = mstDestAddr 
txtSourceAddr.Text = mstSourceAddr 

End Sub 

F. FRMSENDMSGNOW 



Private Sub cmdBack_Click() 

Me.Hide 

frmConstructMsg.Show vbModal 
End Sub 

Private Sub cmdNext_Click() 

Me.Hide 
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’frmSecurityManager.Hide 


Me.Hide 

frmSecurityManager.Show vbModal 
End Sub 

Private Sub cmdQuit_Click() 

End 

End Sub 

Private Sub cmdUpdateStatusFra_Click() 

’when the JoinRequest msg is sent to SAAM, what should the security 
Manager do next? 

1 am still in the same role: RouterB 
T. am still a New Node, not yet Trusted. 

1 am still in the new join scenario 

The only thing to change is my processing state. 

Now I am waiting for a kerberos ticket and authenticator from 
Router A. 

frmStatusFrame.IblProcsStatus_Val.Caption = "Waiting for a Ticket + 
Authenticator..." 
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End Sub 


Private Sub Form_Activate() 

gstMsgContents = frmConstructMsg.txtKeylndex.Text & 
frmConstructMsg.txtMsgAC.Text & _ 
frmConstructMsg.txtRecognitionKey.Text & 
frmConstructMsg.txtDestinationAddr.Text & 
frmConstructMsg.txtSourceAddr.Text & _ 
frmConstructMsg.txtFloID.Text & _ 
frmConstructMsg.txtMessageContents.Text 

If gbSendingKeyTable = True Then 
gstMsgContents = "This is the Encrypted Key Table..." 
gbSendingKeyTable = False 

End If 


txtMsgSent = gstMsgContents 


End Sub 
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G. FRMRCVMSG 


Receiving a Message 




? . 


SAAM has given me a security message. The Packet Factory does not know what type 
of security message this is. That's the Security Manager's job. For demonstration 
purposes only, please select a message. 


Select Message 

Now I am going to process this message 



T rustedSessionRequest 
KeyT ableResponse 
DCM 

UCM_ 


Back 



Next 


Private Sub cmdBack_Click() 

Me.Hide 

frmSecurityManager.Show vbModal 
End Sub 


Private Sub cmdNext_Click() 


Me.Hide 

frmProcsMsg.Show vbModal 
End Sub 


Private Sub cmdQuit_Click() 
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End 


End Sub 


H. FRMPROCSMSG 


*v Processing Message 




Packet Structure- 
Key Index 
jABCD 


Recognition Key Destination Address Source Address Flow ID 

(Textl |Text2 


Msg Contents 


|Text2 


Text2 


|Text3 


If a MAC is present. I am going to try to authenticate this message 




• Read Message—.-.— 


Source Address 

lookup from status frame 

Destination Address 

Textl 

Flow ID | 

Textl 

Message Contents j 

| Textl 


I have determined that this is a message type jjoinRequest 

Therefore. I wBI now do the following: 


send a TrustedSessionRequest msg to KDC 


Back 


Quit 


Next 




Private Sub cmdBack_Click() 


Me.Hide 

frmRcvMsg.Show vbModal 


End Sub 


Private Sub cmdNext_Click() 
Test where to go next. 
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If There is Kerberos stuff to do, then go to the KerberosReferee. 


Me.Hide 

frmKrbRef.Show vbModal 

If there is regular securityManager stuff to do, then go to the Security Manager. 

Me.Hide 

frmSecurityManager.Show vbModal 
End Sub 

Private Sub cmdQuit_Click() 

End 

End Sub 

Private Sub Form_Activate() 

’case KeyTableResponse, don’t show mac because it is not signed. 
IblMsgChosen.Caption = frmChooseMsg.cboMsgList.Text 
If frmRcvMsg.cboMsgList.ItemData = KeyTableResponse Then 
lblMsgAC. Visible = False 
txtMsgAC. Visible = False 


202 





End Sub 


I. FRMKRBREF 


i, Kerberos Referee -1 will produce the Trusted Session Key 


r Authentication Service—-- - 

j Dear KDC at Address: ji 31.120.9.66 

I I would like a TGT please. 

| Sincerely, 

jwhoAml value 

Now the Kerberos Client is extracting the TGT forme. I can look up the TGT value with C+win2K or Java+JCSI. 

{ Hard Coded TGT: jDEFG 

p Ticket Granting Service-— 

I Dear KDC at address:[ 131.120 9 .S 

i would like to speak with the target principle at the following address: [target principle *~~~ 
j Sincerely, 
j jwhoami ” 

j My kerberos client receives the TrustedSessionResponse message from the KDC. SAAM, you do not need to know. 

j Ticket Value: Jv/HASSUP! 


Mutual Authentication -----------.—.— 

My kefberos client has sent the ticket + Authenticator to the target principle. 

Now I am changing who I am to show you a process on the target principle at address: {131.120.9.43 
Does the time in the authenticatof match my time? |y C s ~ ' 

The SecurityState r$ being awarded a Trusted state. 

Now my kerberos client is sending an authenticator back to the sender. 

Now I am changing who I am to show you a process on the sender at address: jTexll 

Does the lime'm the authenticator match my time? Jy e $ Now I trust that target principle at address: j 1 31.120.9.49 

r Get the Trusted Session Key-------------.----—.... 

Now, I am going to extract the session key. Use C+win2K, Java+JCSI. or Had coded. 

Trusted S ession Key Value: jsZCZEPANKJEWICZ 



■Ml xi 


Sack 


Suit 


Next 


Private Sub cmdBack_Click() 


Me.Hide 

frmProcsMsg.Show vbModal 
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End Sub 


Private Sub cmdNext_Click() 

gbSendingKeyTable = True ’Remember that I am going to send the Key Table now. 
Me.Hide 

frmSignDecision.Show vbModal 
End Sub 

Private Sub cmdQuit_Click() 

End 

End Sub 
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